Agda-2.3.2.2/0000755000000000000000000000000012221362553010701 5ustar0000000000000000Agda-2.3.2.2/configure.ac0000644000000000000000000000244012221362553013167 0ustar0000000000000000# -*- Autoconf -*- # Process this file with autoconf to produce a configure script. AC_PREREQ(2.52) AC_INIT([Agda], [2.0], [ulfn@cs.chalmers.se]) # # Check for programs # # C compiler (also does other stuff like figure out extension of executables) AC_PROG_CC # Building Agda AGDA_WITH_PROG_VERSION(GHC,ghc,6.4) AGDA_WITH_PROG_VERSION(ALEX,alex,2.0) AGDA_WITH_PROG_VERSION(HAPPY,happy,1.14) # We need to know if we have ghc 6.6 FP_COMPARE_VERSIONS($GHC_VERSION,[-ge],6.6, [HAVE_GHC_6_6=Yes],[HAVE_GHC_6_6=No] ) AC_SUBST(HAVE_GHC_6_6) # Building the documentation AGDA_WITH_OPTIONAL_PROG_VERSION(HADDOCK,haddock,0.6, [AC_MSG_WARN(haddock is needed to build parts of the documentation.)] ) AGDA_WITH_OPTIONAL_PROG(LATEX,latex) AGDA_WITH_OPTIONAL_PROG(PDFLATEX,pdflatex) AS_IF([test $HAVE_LATEX == No -a $HAVE_PDFLATEX == No], [AC_MSG_WARN(You need at least one of latex and pdflatex to build parts of the documentation.) ] ) # Utility programs AC_PROG_INSTALL AGDA_WITH_OPTIONAL_PROG(WGET,wget) AGDA_WITH_PROG(FALSE,false) AGDA_WITH_PROG(FIND,find) AGDA_WITH_PROG(DIFF,diff) AGDA_WITH_OPTIONAL_PROG(DARCS,darcs) AGDA_WITH_PROG(MKDIR,mkdir) AGDA_WITH_OPTIONAL_PROG(RUNHASKELL,runhaskell) # Output AC_CONFIG_FILES([mk/config.mk]) AC_OUTPUT Agda-2.3.2.2/HACKING0000644000000000000000000000327412221362553011676 0ustar0000000000000000Some Agda Hacking Lore * Whenever you change the interface file format you should update Agda.TypeChecking.Serialise.currentInterfaceVersion. * When a new feature is implemented it should be documented in doc/release-notes/.txt. It is also a good idea to add test cases under test/succeed and test/fail, and maybe also test/interaction. When adding test cases under test/fail, remember to record the error messages (.err files) after running make test. * Run the test-suite, using make test (which does not work properly unless you run autoreconf and ./configure first). Tests under test/fail can fail if an error message has changed. To accept the new error message, touch the corresponding source file. * Under darcs 2.5 the --test flag is not enabled by default. This can be changed by adding the following line to _darcs/prefs/defaults: ALL test * To avoid problems with the whitespace test failing you can add the following line to _darcs/prefs/defaults: record prehook make fix-whitespace * Use __IMPOSSIBLE__ instead of calls to error. __IMPOSSIBLE__ generates errors of the following form: An internal error has occurred. Please report this as a bug. Location of the error: ... Calls to error can make Agda fail with an error message in the *ghci* buffer. Emacs mode * Load times (wall-clock time) can be measured using agda2-measure-load-time. * If you fix a bug related to syntax highlighting, please add a test case under test/interaction. Example .in file command: IOTCM "Foo.agda" NonInteractive Direct (Cmd_load "Foo.agda" []) If you want to include interactive highlighting directives, replace NonInteractive with Interactive. Agda-2.3.2.2/Setup.hs0000644000000000000000000000100112221362553012325 0ustar0000000000000000import Distribution.Simple main = defaultMain -- The following comment may be relevant for agda-pkg: -- -- Although this looks like the Simple build type, it is in fact vital that -- we use this Setup.hs because it'll get compiled against the local copy -- of the Cabal lib, thus enabling Cabal to bootstrap itself without relying -- on any previous installation. This also means we can use any new features -- immediately because we never have to worry about building Cabal with an -- older version of itself. Agda-2.3.2.2/aclocal.m40000644000000000000000000000013212221362553012535 0ustar0000000000000000 m4_include(macros/fptools.m4) m4_include(macros/utils.m4) m4_include(macros/haskell.m4) Agda-2.3.2.2/.darcsignore0000644000000000000000000000321112221362553013177 0ustar0000000000000000(^|/)CVS$ \.(swp|swo)$ ^autom4te.cache$ ^config.log$ ^configure$ ^config.status$ ^mk/config.mk$ ^out$ ^doc/haddock/src$ ^doc/haddock/.*\.(gif|html|css|js|haddock) ^tmp$ ^doc/pfe/fake/Syntax/Parser/(Parser|Lexer)\.hs$ \.(log|ps|aux|bbl|nav|bak|snm|toc)$ ^doc/.*\.out$ \.happy.out$ \.dvi$ \.pdf$ ~$ trace/(lam|lambda)$ Agda2\.tar\.gz \.agdai$ (^|/)\..*\.l?agda\.vim$ \.blg$ \.DS_Store$ \.(o|hi)$ src/prototyping/eval/Lam$ src/prototyping/eval/prof$ src/prototyping/eval/(eval|eval_p)$ src/prototyping/eval/.*\.prof$ \.hp$ (^|/)tags$ notes/papers/implicit/(examples|lhs2TeXpreamble|exintro).tex src/prototyping/modules/flat/Syntax$ src/prototyping/modules/flat/module$ \.vrb$ (^|/)dist$ ^\.(inplace-pkg|installed-pkg|setup)-config$ ^src/main/setup$ ^setup$ ^src/main/dist$ ^src/full/Syntax/Parser/(Parser|Lexer).hs$ ^src/main/.uptodate$ \#.*\#$ \.agda\.html$ notes/papers/iird/paper.tex \.setup-config$ src/transl/dist src/rts/dist \.(installed|inplace)-pkg-config examples/cbs/agda1 \.prof$ src/hTags/dist$ fileIO/.*\.hs$ fileIO/Main$ src/prototyping/nameless/(nameless|Lam)$ examples/simple-lib/.*\.hs ^std-lib$ examples/MAlonzo/MAlonzo$ examples/MAlonzo/main$ test/fail/(Epic|MAlonzo)$ test/epic/(RunTests|Epic)$ test/epic/tests/bin/.* test/compiler/(Main|MAlonzo)$ ^src/agda-pkg/dist$ src/prototyping/terms/(dist|term)$ ^examples/relocatable/copies$ ^test/succeed/MAlonzo($|/) ^test/succeed/Issue(296|326)$ examples/compiler/MAlonzo$ test/succeed/Epic$ examples/compiler/main$ test/fail/customised/MAlonzo$ examples/compiler/Epic$ test/interaction/MAlonzo$ prototyping/termrep/(bug|Main|Syntax/((Abs|ErrM|Layout|Lex|Par|Print|Skel|Test)\.hs|Par\.y|Lex.x|Doc\.(tex|txt)))$ Agda-2.3.2.2/LICENSE0000644000000000000000000000550412221362553011712 0ustar0000000000000000Copyright (c) 2005-2013 Ulf Norell, Nils Anders Danielsson, Catarina Coquand, Makoto Takeyama, Andreas Abel, Karl Mehltretter, Marcin Benke, Darin Morrison. Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. -------------------------------------------------------------------------------- The file src/full/Agda/Utils/ReadP.hs is Copyright (c) The University of Glasgow 2002 and is licensed under a BSD-like license as follows: Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: - Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. - Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. - Neither name of the University nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE UNIVERSITY COURT OF THE UNIVERSITY OF GLASGOW AND THE CONTRIBUTORS "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 UNIVERSITY COURT OF THE UNIVERSITY OF GLASGOW OR THE CONTRIBUTORS 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. Agda-2.3.2.2/.authorspellings0000644000000000000000000000121512221362553014124 0ustar0000000000000000Ulf Norell , ulfn@chalmers\.se, ^ulfn@cs\.chalmers\.se$ Nils Anders Danielsson , ^Nils Anders Danielsson $ Andreas Abel , andreas\.abel@ifi\.lmu\.de, ^abel@cs\.chalmers\.se$ Andrés Sicard-Ramírez , ^andres\.sicard\.ramirez@gmail\.com$, ^andres\.sicard@gmail\.com$ Fredrik Lindblad , frelindb@chalmers\.se Dominique Devriese , ^dominique\.devriese@gmail\.com$, ^dominique\.devriese@cs\.kuleuven\.be$ Darin Morrison , ^darinmorrison@gmail\.com$ Agda-2.3.2.2/install-sh0000644000000000000000000001273612221362553012713 0ustar0000000000000000#!/bin/sh # # install - install a program, script, or datafile # This comes from X11R5 (mit/util/scripts/install.sh). # # Copyright 1991 by the Massachusetts Institute of Technology # # Permission to use, copy, modify, distribute, and sell this software and its # documentation for any purpose is hereby granted without fee, provided that # the above copyright notice appear in all copies and that both that # copyright notice and this permission notice appear in supporting # documentation, and that the name of M.I.T. not be used in advertising or # publicity pertaining to distribution of the software without specific, # written prior permission. M.I.T. makes no representations about the # suitability of this software for any purpose. It is provided "as is" # without express or implied warranty. # # Calling this script install-sh is preferred over install.sh, to prevent # `make' implicit rules from creating a file called install from it # when there is no Makefile. # # This script is compatible with the BSD install script, but was written # from scratch. It can only install one file at a time, a restriction # shared with many OS's install programs. # set DOITPROG to echo to test this script # Don't use :- since 4.3BSD and earlier shells don't like it. doit="${DOITPROG-}" # put in absolute paths if you don't have them in your path; or use env. vars. mvprog="${MVPROG-mv}" cpprog="${CPPROG-cp}" chmodprog="${CHMODPROG-chmod}" chownprog="${CHOWNPROG-chown}" chgrpprog="${CHGRPPROG-chgrp}" stripprog="${STRIPPROG-strip}" rmprog="${RMPROG-rm}" mkdirprog="${MKDIRPROG-mkdir}" transformbasename="" transform_arg="" instcmd="$mvprog" chmodcmd="$chmodprog 0755" chowncmd="" chgrpcmd="" stripcmd="" rmcmd="$rmprog -f" mvcmd="$mvprog" src="" dst="" dir_arg="" while [ x"$1" != x ]; do case $1 in -c) instcmd="$cpprog" shift continue;; -d) dir_arg=true shift continue;; -m) chmodcmd="$chmodprog $2" shift shift continue;; -o) chowncmd="$chownprog $2" shift shift continue;; -g) chgrpcmd="$chgrpprog $2" shift shift continue;; -s) stripcmd="$stripprog" shift continue;; -t=*) transformarg=`echo $1 | sed 's/-t=//'` shift continue;; -b=*) transformbasename=`echo $1 | sed 's/-b=//'` shift continue;; *) if [ x"$src" = x ] then src=$1 else # this colon is to work around a 386BSD /bin/sh bug : dst=$1 fi shift continue;; esac done if [ x"$src" = x ] then echo "install: no input file specified" exit 1 else true fi if [ x"$dir_arg" != x ]; then dst=$src src="" if [ -d $dst ]; then instcmd=: chmodcmd="" else instcmd=mkdir fi else # Waiting for this to be detected by the "$instcmd $src $dsttmp" command # might cause directories to be created, which would be especially bad # if $src (and thus $dsttmp) contains '*'. if [ -f $src -o -d $src ] then true else echo "install: $src does not exist" exit 1 fi if [ x"$dst" = x ] then echo "install: no destination specified" exit 1 else true fi # If destination is a directory, append the input filename; if your system # does not like double slashes in filenames, you may need to add some logic if [ -d $dst ] then dst="$dst"/`basename $src` else true fi fi ## this sed command emulates the dirname command dstdir=`echo $dst | sed -e 's,[^/]*$,,;s,/$,,;s,^$,.,'` # Make sure that the destination directory exists. # this part is taken from Noah Friedman's mkinstalldirs script # Skip lots of stat calls in the usual case. if [ ! -d "$dstdir" ]; then defaultIFS=' ' IFS="${IFS-${defaultIFS}}" oIFS="${IFS}" # Some sh's can't handle IFS=/ for some reason. IFS='%' set - `echo ${dstdir} | sed -e 's@/@%@g' -e 's@^%@/@'` IFS="${oIFS}" pathcomp='' while [ $# -ne 0 ] ; do pathcomp="${pathcomp}${1}" shift if [ ! -d "${pathcomp}" ] ; then $mkdirprog "${pathcomp}" else true fi pathcomp="${pathcomp}/" done fi if [ x"$dir_arg" != x ] then $doit $instcmd $dst && if [ x"$chowncmd" != x ]; then $doit $chowncmd $dst; else true ; fi && if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dst; else true ; fi && if [ x"$stripcmd" != x ]; then $doit $stripcmd $dst; else true ; fi && if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dst; else true ; fi else # If we're going to rename the final executable, determine the name now. if [ x"$transformarg" = x ] then dstfile=`basename $dst` else dstfile=`basename $dst $transformbasename | sed $transformarg`$transformbasename fi # don't allow the sed command to completely eliminate the filename if [ x"$dstfile" = x ] then dstfile=`basename $dst` else true fi # Make a temp file name in the proper directory. dsttmp=$dstdir/#inst.$$# # Move or copy the file name to the temp name $doit $instcmd $src $dsttmp && trap "rm -f ${dsttmp}" 0 && # and set any options; do chmod last to preserve setuid bits # If any of these fail, we abort the whole thing. If we want to # ignore errors from any of these, just make sure not to ignore # errors from the above "$doit $instcmd $src $dsttmp" command. if [ x"$chowncmd" != x ]; then $doit $chowncmd $dsttmp; else true;fi && if [ x"$chgrpcmd" != x ]; then $doit $chgrpcmd $dsttmp; else true;fi && if [ x"$stripcmd" != x ]; then $doit $stripcmd $dsttmp; else true;fi && if [ x"$chmodcmd" != x ]; then $doit $chmodcmd $dsttmp; else true;fi && # Now rename the file to the real destination. $doit $rmcmd -f $dstdir/$dstfile && $doit $mvcmd $dsttmp $dstdir/$dstfile fi && exit 0 Agda-2.3.2.2/Agda.cabal0000644000000000000000000003757712221362553012544 0ustar0000000000000000name: Agda version: 2.3.2.2 cabal-version: >= 1.8 build-type: Simple license: OtherLicense license-file: LICENSE author: Ulf Norell, Nils Anders Danielsson, Andreas Abel, Makoto Takeyama, Catarina Coquand, with contributions by Stevan Andjelkovic, Marcin Benke, Jean-Philippe Bernardy, James Chapman, Dominique Devriese, Peter Divanski, Fredrik Nordvall Forsberg, Olle Frediksson, Daniel Gustafsson, Alan Jeffrey, Fredrik Lindblad, Guilhem Moulin, Nicolas Pouillard, Andrés Sicard-Ramírez and many more. maintainer: Ulf Norell homepage: http://wiki.portal.chalmers.se/agda/ bug-reports: http://code.google.com/p/agda/issues/list category: Dependent types synopsis: A dependently typed functional programming language and proof assistant description: Agda is a dependently typed functional programming language: It has inductive families, which are similar to Haskell's GADTs, but they can be indexed by values and not just types. It also has parameterised modules, mixfix operators, Unicode characters, and an interactive Emacs interface (the type checker can assist in the development of your code). . Agda is also a proof assistant: It is an interactive system for writing and checking proofs. Agda is based on intuitionistic type theory, a foundational system for constructive mathematics developed by the Swedish logician Per Martin-Löf. It has many similarities with other proof assistants based on dependent types, such as Coq, Epigram and NuPRL. . This package includes both a command-line program (agda) and an Emacs mode. If you want to use the Emacs mode you can set it up by running @agda-mode setup@ (see the README). . Note that the Agda library does not follow the package versioning policy, because it is not intended to be used by third-party packages. tested-with: GHC == 7.6.3 extra-source-files: src/full/Agda/undefined.h README doc/release-notes/*.txt data-dir: src/data data-files: Agda.css emacs-mode/*.el EpicInclude/AgdaPrelude.e EpicInclude/stdagda.c EpicInclude/stdagda.h agda.sty source-repository head type: darcs location: http://code.haskell.org/Agda/ source-repository this type: darcs location: http://code.haskell.org/Agda/ tag: 2.3.2.2 flag epic default: False manual: True description: Install the Epic compiler. library hs-source-dirs: src/full if flag(epic) build-depends: epic >= 0.1.13 && < 0.10 if os(windows) build-depends: Win32 >= 2.2 && < 2.4 build-depends: base >= 4.2 && < 4.7, -- mtl-2.1 contains a severe bug mtl >= 2.0 && < 2.1 || >= 2.1.1 && < 2.2, QuickCheck >= 2.3 && < 2.7, haskell-src-exts >= 1.9.6 && < 1.15, containers >= 0.1 && < 0.6, unordered-containers == 0.2.*, pretty >= 1.0 && < 1.2, bytestring >= 0.9.0.1 && < 0.11, array >= 0.1 && < 0.5, binary >= 0.4.4 && < 0.6, zlib >= 0.4.0.1 && < 0.6, filepath >= 1.1 && < 1.4, process >= 1.0.1.0 && < 1.2, haskeline >= 0.6.3.2 && < 0.8, xhtml == 3000.2.*, -- hashable 1.2.0.10 makes library-test 10x -- slower. The issue was fixed in hashable 1.2.1.0. -- https://github.com/tibbe/hashable/issues/57. hashable >= 1.1.2.3 && < 1.2 || >= 1.2.1.0 && < 1.3, hashtables >= 1.0 && < 1.2, geniplate >= 0.6.0.3 && < 0.7, parallel < 3.3, deepseq == 1.3.*, text == 0.11.* if impl(ghc < 7.6) build-depends: old-time >= 1.0 && < 1.2, directory >= 1.0 && < 1.2 else build-depends: time == 1.4.*, directory == 1.2.* build-tools: happy >= 1.15 && < 2, alex >= 2.3.1 && < 3.2 extensions: CPP exposed-modules: Agda.Main Agda.ImpossibleTest Agda.Interaction.BasicOps Agda.Interaction.GhcTop Agda.Interaction.InteractionTop Agda.Compiler.CallCompiler Agda.Compiler.HaskellTypes Agda.Compiler.Epic.AuxAST Agda.Compiler.Epic.CaseOpts Agda.Compiler.Epic.Compiler Agda.Compiler.Epic.CompileState Agda.Compiler.Epic.Epic Agda.Compiler.Epic.Erasure Agda.Compiler.Epic.ForceConstrs Agda.Compiler.Epic.Forcing Agda.Compiler.Epic.FromAgda Agda.Compiler.Epic.Injection Agda.Compiler.Epic.Interface Agda.Compiler.Epic.NatDetection Agda.Compiler.Epic.Primitive Agda.Compiler.Epic.Smashing Agda.Compiler.Epic.Static Agda.Compiler.JS.Case Agda.Compiler.JS.Compiler Agda.Compiler.JS.Syntax Agda.Compiler.JS.Substitution Agda.Compiler.JS.Parser Agda.Compiler.JS.Pretty Agda.Compiler.MAlonzo.Compiler Agda.Compiler.MAlonzo.Encode Agda.Compiler.MAlonzo.Misc Agda.Compiler.MAlonzo.Pretty Agda.Compiler.MAlonzo.Primitives Agda.Packaging.Config Agda.Packaging.Database Agda.Packaging.Monad Agda.Packaging.Types Agda.Interaction.CommandLine.CommandLine Agda.Interaction.EmacsCommand Agda.Interaction.Exceptions Agda.Interaction.FindFile Agda.Interaction.Highlighting.Dot Agda.Interaction.Highlighting.Emacs Agda.Interaction.Highlighting.Generate Agda.Interaction.Highlighting.HTML Agda.Interaction.Highlighting.Precise Agda.Interaction.Highlighting.Range Agda.Interaction.Highlighting.Vim Agda.Interaction.Highlighting.LaTeX Agda.Interaction.Imports Agda.Interaction.Response Agda.Interaction.MakeCase Agda.Interaction.Monad Agda.Interaction.Options Agda.Syntax.Abstract.Copatterns Agda.Syntax.Abstract.Name Agda.Syntax.Abstract.Pretty Agda.Syntax.Abstract.Views Agda.Syntax.Abstract Agda.Syntax.Common Agda.Syntax.Concrete.Definitions Agda.Syntax.Concrete.Name Agda.Syntax.Concrete.Operators.Parser Agda.Syntax.Concrete.Operators Agda.Syntax.Concrete.Pretty Agda.Syntax.Concrete Agda.Syntax.Fixity Agda.Syntax.Info Agda.Syntax.Internal Agda.Syntax.Internal.Generic Agda.Syntax.Internal.Pattern Agda.Syntax.Literal Agda.Syntax.Notation Agda.Syntax.Parser.Alex Agda.Syntax.Parser.Comments Agda.Syntax.Parser.Layout Agda.Syntax.Parser.LexActions Agda.Syntax.Parser.Lexer Agda.Syntax.Parser.LookAhead Agda.Syntax.Parser.Monad Agda.Syntax.Parser.Parser Agda.Syntax.Parser.StringLiterals Agda.Syntax.Parser.Tokens Agda.Syntax.Parser Agda.Syntax.Position Agda.Syntax.Scope.Base Agda.Syntax.Scope.Monad Agda.Syntax.Translation.AbstractToConcrete Agda.Syntax.Translation.ConcreteToAbstract Agda.Syntax.Translation.InternalToAbstract Agda.Termination.CallGraph Agda.Termination.Lexicographic Agda.Termination.Matrix Agda.Termination.SparseMatrix Agda.Termination.Semiring Agda.Termination.TermCheck Agda.Termination.Termination Agda.Tests Agda.TypeChecker Agda.TypeChecking.Abstract Agda.TypeChecking.CompiledClause Agda.TypeChecking.CompiledClause.Compile Agda.TypeChecking.CompiledClause.Match Agda.TypeChecking.Constraints Agda.TypeChecking.Conversion Agda.TypeChecking.Coverage Agda.TypeChecking.Coverage.Match Agda.TypeChecking.Coverage.SplitTree Agda.TypeChecking.Datatypes Agda.TypeChecking.DisplayForm Agda.TypeChecking.DropArgs Agda.TypeChecking.Eliminators Agda.TypeChecking.Empty Agda.TypeChecking.EtaContract Agda.TypeChecking.Errors Agda.TypeChecking.Free Agda.TypeChecking.Forcing Agda.TypeChecking.Implicit Agda.TypeChecking.Injectivity Agda.TypeChecking.InstanceArguments Agda.TypeChecking.Irrelevance Agda.TypeChecking.Level Agda.TypeChecking.LevelConstraints Agda.TypeChecking.MetaVars Agda.TypeChecking.MetaVars.Mention Agda.TypeChecking.MetaVars.Occurs Agda.TypeChecking.Monad.Base Agda.TypeChecking.Monad.Builtin Agda.TypeChecking.Monad.Closure Agda.TypeChecking.Monad.Constraints Agda.TypeChecking.Monad.Context Agda.TypeChecking.Monad.Debug Agda.TypeChecking.Monad.Env Agda.TypeChecking.Monad.Exception Agda.TypeChecking.Monad.Imports Agda.TypeChecking.Monad.MetaVars Agda.TypeChecking.Monad.Mutual Agda.TypeChecking.Monad.Open Agda.TypeChecking.Monad.Options Agda.TypeChecking.Monad.Sharing Agda.TypeChecking.Monad.Signature Agda.TypeChecking.Monad.SizedTypes Agda.TypeChecking.Monad.State Agda.TypeChecking.Monad.Statistics Agda.TypeChecking.Monad.Trace Agda.TypeChecking.Monad Agda.TypeChecking.Patterns.Match Agda.TypeChecking.Polarity Agda.TypeChecking.Positivity Agda.TypeChecking.Pretty Agda.TypeChecking.Primitive Agda.TypeChecking.ProjectionLike Agda.TypeChecking.Quote Agda.TypeChecking.Rebind Agda.TypeChecking.RecordPatterns Agda.TypeChecking.Records Agda.TypeChecking.Reduce Agda.TypeChecking.Rules.Builtin Agda.TypeChecking.Rules.Builtin.Coinduction Agda.TypeChecking.Rules.Data Agda.TypeChecking.Rules.Decl Agda.TypeChecking.Rules.Def Agda.TypeChecking.Rules.LHS Agda.TypeChecking.Rules.LHS.Implicit Agda.TypeChecking.Rules.LHS.Instantiate Agda.TypeChecking.Rules.LHS.Problem Agda.TypeChecking.Rules.LHS.ProblemRest Agda.TypeChecking.Rules.LHS.Split Agda.TypeChecking.Rules.LHS.Unify Agda.TypeChecking.Rules.Record Agda.TypeChecking.Rules.Term Agda.TypeChecking.Serialise Agda.TypeChecking.SizedTypes Agda.TypeChecking.Substitute Agda.TypeChecking.Telescope Agda.TypeChecking.Test.Generators Agda.TypeChecking.Tests Agda.TypeChecking.UniversePolymorphism Agda.TypeChecking.With Agda.Utils.VarSet Agda.Utils.Char Agda.Utils.Either Agda.Utils.FileName Agda.Utils.Fresh Agda.Utils.Function Agda.Utils.Geniplate Agda.Utils.Graph Agda.Utils.Hash Agda.Utils.HashMap Agda.Utils.Impossible Agda.Utils.IO.Binary Agda.Utils.IO.UTF8 Agda.Utils.List Agda.Utils.Map Agda.Utils.Maybe Agda.Utils.Monad Agda.Utils.Permutation Agda.Utils.Pointer Agda.Utils.Pointed Agda.Utils.Pretty Agda.Utils.QuickCheck Agda.Utils.ReadP Agda.Utils.SemiRing Agda.Utils.Size Agda.Utils.String Agda.Utils.Suffix Agda.Utils.TestHelpers Agda.Utils.Time Agda.Utils.Trie Agda.Utils.Tuple Agda.Utils.Unicode Agda.Utils.Warshall Agda.Version Agda.Auto.Auto Agda.Auto.Convert Agda.Auto.Typecheck Agda.Auto.NarrowingSearch Agda.Auto.Syntax Agda.Auto.SearchControl Agda.Auto.CaseSplit other-modules: Paths_Agda if true ghc-options: -w -fwarn-deprecated-flags -fwarn-dodgy-foreign-imports -fwarn-dodgy-imports -fwarn-duplicate-exports -fwarn-hi-shadowing -fwarn-incomplete-patterns -fwarn-missing-fields -fwarn-missing-methods -fwarn-overlapping-patterns -fwarn-warnings-deprecations if impl(ghc >= 6.12) ghc-options: -fwarn-dodgy-exports -fwarn-wrong-do-bind if impl(ghc >= 7.2) ghc-options: -fwarn-identities ghc-prof-options: -auto-all executable agda hs-source-dirs: src/main main-is: Main.hs build-depends: Agda == 2.3.2.2, -- Nothing is used from the following package, except -- for the prelude. base >= 3 && < 6 if impl(ghc >= 7) -- If someone installs Agda with the setuid bit set, then the -- presence of +RTS may be a security problem (see GHC bug #3910). -- However, we sometimes recommend people to use +RTS to control -- Agda's memory usage, so we want this functionality enabled by -- default. ghc-options: -rtsopts executable agda-mode hs-source-dirs: src/agda-mode main-is: Main.hs other-modules: Paths_Agda build-depends: base >= 4.2 && < 4.7, filepath >= 1.1 && < 1.4, process >= 1.0.1.0 && < 1.2, directory >= 1.0 && < 1.3 Agda-2.3.2.2/Makefile0000644000000000000000000001763312221362553012353 0ustar0000000000000000# Top-level Makefile for Agda 2 # Authors: Ulf Norell, Nils Anders Danielsson SHELL=bash ## Includes ############################################################### TOP = . is_configured = $(shell if test -f mk/config.mk; \ then echo Yes; \ else echo No; \ fi \ ) include mk/paths.mk ifeq ($(is_configured),Yes) include mk/config.mk include mk/rules.mk endif ## Phony targets ########################################################## .PHONY : default all clean install full prof core \ debug doc dist make_configure clean_test examples \ test tests succeed fail interaction benchmark up-to-date-std-lib \ update-cabal install-lib install-bin install-emacs-mode ## Default target ######################################################### ifeq ($(is_configured),Yes) default : compile-emacs-mode # tags else default : make_configure endif ## Cabal-based installation ############################################### # The cabal command. CABAL_CMD=cabal # Options used by cabal install. CABAL_OPTIONS= # -f epic install : update-cabal install-bin compile-emacs-mode setup-emacs-mode prof : install-prof-bin update-cabal : $(CABAL_CMD) update # Installs the Emacs mode, but does not set it up. install-bin : $(CABAL_CMD) install --disable-library-profiling --disable-documentation $(CABAL_OPTIONS) install-prof-bin : $(CABAL_CMD) install --enable-library-profiling --enable-executable-profiling \ --program-suffix=_p --disable-documentation $(CABAL_OPTIONS) compile-emacs-mode : install-bin agda-mode compile setup-emacs-mode : install-bin @echo @echo "If the agda-mode command is not found, make sure that the directory" @echo "in which it was installed is located on your shell's search path." @echo agda-mode setup ## Making the make system ################################################# m4_macros = $(wildcard $(MACRO_DIR)/*.m4) make_configure : configure @echo "Run './configure' to set up the build system." configure : aclocal.m4 $(m4_macros) configure.ac autoconf ## ## The following targets are only available after running configure ####### ## ifeq ($(is_configured),Yes) ## Making the documentation ############################################### doc : $(MAKE) -C $(HADDOCK_DIR) ## Making the full language ############################################### ifeq ($(HAVE_RUNHASKELL),Yes) SETUP = Setup.hs RUNSETUP = $(RUNHASKELL) $(SETUP) else SETUP = setup RUNSETUP = ./setup $(SETUP) : Setup.hs ghc --make -o $@ $< endif CONFIG = dist/setup-config CABAL = Agda.cabal BUILD = dist/build-complete INPLACE = dist/installed-inplace SOURCES = $(shell $(FIND) $(FULL_SRC_DIR) -name '*hs') \ $(shell $(FIND) $(FULL_SRC_DIR) -name '*.y') \ $(shell $(FIND) $(FULL_SRC_DIR) -name '*.x') $(CONFIG) : $(CABAL) $(SETUP) $(RUNSETUP) configure $(BUILD) : $(CONFIG) $(SOURCES) $(RUNSETUP) build @date > $@ $(INPLACE) : $(BUILD) $(RUNSETUP) register --user --inplace @date > $@ $(AGDA_BIN) : $(INPLACE) $(MAIN_SRC_DIR)/Main.hs $(MAKE) -C $(MAIN_SRC_DIR) full : $(AGDA_BIN) ## Making the core language ############################################### core : $(MAKE) -C $(CORE_SRC_DIR) ## Making the Agda 1 to Agda 2 translator ################################# transl : (cd $(TRANSL_SRC_DIR); cabal configure && cabal build) ## Making the source distribution ######################################### ifeq ($(HAVE_DARCS)-$(shell if test -d _darcs; then echo darcs; fi),Yes-darcs) is_darcs_repo = Yes else is_darcs_repo = No endif ifeq ($(is_darcs_repo),Yes) dist : agda2.tar.gz agda2.tar.gz : $(DARCS) dist -d agda2 else dist : @echo You can only "'make dist'" from the darcs repository. @$(FALSE) endif tags : $(MAKE) -C $(FULL_SRC_DIR) tags TAGS : $(MAKE) -C $(FULL_SRC_DIR) TAGS ## Testing ########################################################### test : check-whitespace succeed fail interaction examples tests library-test compiler-test lib-succeed epic-test tests : @echo "======================================================================" @echo "======================== Internal test suite =========================" @echo "======================================================================" $(AGDA_BIN) --test succeed : @echo "======================================================================" @echo "===================== Suite of successfull tests =====================" @echo "======================================================================" @chmod +x test/succeed/checkOutput @$(MAKE) -C test/succeed interaction : @echo "======================================================================" @echo "===================== Suite of interaction tests =====================" @echo "======================================================================" @$(MAKE) -C test/interaction examples : @echo "======================================================================" @echo "========================= Suite of examples ==========================" @echo "======================================================================" @$(MAKE) -C examples fail : @echo "======================================================================" @echo "======================= Suite of failing tests =======================" @echo "======================================================================" @$(MAKE) -C test/fail std-lib : darcs get --lazy --repo-name=$@ \ http://www.cse.chalmers.se/~nad/repos/lib/ up-to-date-std-lib : std-lib @(cd std-lib && darcs pull -a && make setup) library-test : up-to-date-std-lib @echo "======================================================================" @echo "========================== Standard library ==========================" @echo "======================================================================" @(cd std-lib && \ time $(PWD)/$(AGDA_BIN) -i. -isrc README.agda $(AGDA_TEST_FLAGS) \ +RTS -s) compiler-test : up-to-date-std-lib @echo "======================================================================" @echo "============================== Compiler ==============================" @echo "======================================================================" @(cd test/compiler && \ time ../../$(AGDA_BIN) --compile -i. -i../../std-lib -i../../std-lib/src \ Main.agda +RTS -H1G -M1.5G && \ ./Main) lib-succeed : @echo "======================================================================" @echo "========== Successfull tests using the standard library ==============" @echo "======================================================================" @$(MAKE) -C test/$@ epic-test : @echo "======================================================================" @echo "============================ Epic backend ============================" @echo "======================================================================" @$(MAKE) -C test/epic benchmark : @$(MAKE) -C benchmark ## Clean ################################################################## clean : $(MAKE) -C $(HADDOCK_DIR) clean rm -rf $(OUT_DIR) rm -rf dist veryclean : $(MAKE) -C $(HADDOCK_DIR) veryclean rm -rf $(OUT_DIR) rm -rf configure config.log config.status autom4te.cache mk/config.mk ## Debugging the Makefile ################################################# info : @echo "The agda binary is at: $(AGDA_BIN)" @echo "Do we have ghc 6.4? $(HAVE_GHC_6_4)" @echo "Is this the darcs repository? $(is_darcs_repo)" else # is_configured info : @echo "You haven't run configure." endif # is_configured ## Whitespace-related ##################################################### # Agda can fail to compile on Windows if files which are CPP-processed # don't end with a newline character (because we use -Werror). .PHONY: fix-whitespace : fix-agda-whitespace .PHONY: check-whitespace : fix-agda-whitespace --check .PHONY: install-fix-agda-whitespace : cd src/fix-agda-whitespace && \ $(CABAL_CMD) install $(CABAL_OPTIONS) Agda-2.3.2.2/README0000644000000000000000000002653112221362553011570 0ustar0000000000000000======================================================================== Agda 2 ======================================================================== Table of contents: * Installing Agda * Configuring the Emacs mode * Prerequisites * Installing the Epic backend's dependencies * Installing a suitable version of Emacs under Windows ------------------------------------------------------------------------ Installing Agda ------------------------------------------------------------------------ Note that this README only discusses installation of Agda, not its standard library. See the Agda Wiki for information about the library. There are several ways to install Agda: * Using a binary package, prepared for your platform. Recommended if such a package exists. See the Agda Wiki. * Using a released source package, available from Hackage. (Note that if you want to install the development version of Agda, then you should use the next method.) Install the prerequisites mentioned below, then run the following commands: cabal update cabal install Agda agda-mode setup The last command tries to set up Emacs for use with Agda. As an alternative you can copy the following text to your .emacs file: (load-file (let ((coding-system-for-read 'utf-8)) (shell-command-to-string "agda-mode locate"))) It is also possible (but not necessary) to compile the Emacs mode's files: agda-mode compile This can, in some cases, give a noticeable speedup. WARNING: If you reinstall the Agda mode without recompiling the Emacs Lisp files, then Emacs may continue using the old, compiled files. * Using the source tar balls available from the Agda Wiki, or the development version of the code available from our darcs repository. 1) Install the prerequisites mentioned below. 2a) Run the following commands in the top-level directory of the Agda source tree: cabal update cabal install agda-mode setup The last command tries to set up Emacs for use with Agda. As an alternative you can copy the following text to your .emacs file: (load-file (let ((coding-system-for-read 'utf-8)) (shell-command-to-string "agda-mode locate"))) If you want to have more control over where files are installed then you can give various flags to cabal install, see cabal install --help. It is also possible (but not necessary) to compile the Emacs mode's files: agda-mode compile This can, in some cases, give a noticeable speedup. WARNING: If you reinstall the Agda mode without recompiling the Emacs Lisp files, then Emacs may continue using the old, compiled files. 2b) Instead of following 2a you can try to install Agda (including a compiled Emacs mode) by running the following command: make install ------------------------------------------------------------------------ Configuring the Emacs mode ------------------------------------------------------------------------ If you want to you can customise the Emacs mode. Just start Emacs and type the following: M-x load-library RET agda2-mode RET M-x customize-group RET agda2 RET This is useful if you want to change the Agda search path, in which case you should change the agda2-include-dirs variable. If you want some specific settings for the Emacs mode you can add them to agda2-mode-hook. For instance, if you do not want to use the Agda input method (for writing various symbols like ∀≥ℕ→π⟦⟧) you can add the following to your .emacs: (add-hook 'agda2-mode-hook '(lambda () ; If you do not want to use any input method: (inactivate-input-method) ; If you want to use the X input method: (set-input-method "X") )) Note that, on some systems, the Emacs mode changes the default font of the current frame in order to enable many Unicode symbols to be displayed. This only works if the right fonts are available, though. If you want to turn off this feature, then you should customise the agda2-fontset-name variable. ------------------------------------------------------------------------ Prerequisites ------------------------------------------------------------------------ You need recent versions of the following programs/libraries: GHC: http://www.haskell.org/ghc/ cabal-install: http://www.haskell.org/cabal/ Alex: http://www.haskell.org/alex/ Happy: http://www.haskell.org/happy/ GNU Emacs: http://www.gnu.org/software/emacs/ You should also make sure that programs installed by cabal-install are on your shell's search path. For instructions on installing a suitable version of Emacs under Windows, see below. Non-Windows users need to ensure that the development files for the C libraries zlib and ncurses are installed (see http://zlib.net and http://www.gnu.org/software/ncurses/). Your package manager may be able to install these files for you. For instance, on Debian or Ubuntu it should suffice to run apt-get install zlib1g-dev libncurses5-dev as root to get the correct files installed. ------------------------------------------------------------------------ Installing the Epic backend's dependencies ------------------------------------------------------------------------ The Epic backend is experimental and requires that the Epic program is installed. You can install this program by giving the epic flag to cabal (but note that, at the time of writing, the Epic program does not build with certain recent versions of GHC): * When installing from Hackage: cabal update cabal install Agda -fepic agda-mode setup * When installing using a source tar ball, following the instructions in 2a) above: cabal update cabal install -fepic agda-mode setup * When installing using a source tar ball, following the instructions in 2b) above: make CABAL_OPTIONS=-fepic install You can also install Epic directly: cabal install epic Note that Epic depends on other software: The Boehm garbage collector: http://www.hpl.hp.com/personal/Hans_Boehm/gc/ The GNU Multiple Precision Arithmetic Library: http://gmplib.org/ GCC, the GNU Compiler Collection: http://gcc.gnu.org/ For more information about Epic: http://www.cs.st-andrews.ac.uk/~eb/epic.php ------------------------------------------------------------------------ Installing a suitable version of Emacs under Windows ------------------------------------------------------------------------ Note that Agda code often uses mathematical and other symbols available from the Unicode character set. In order to be able to display these characters you may want to follow the procedure below when installing Emacs under Windows. (Note: These instructions are possibly outdated.) 1. Install NTEmacs 22. Download from http://ntemacs.sourceforge.net/ the self-extracting executable ntemacs22-bin-20070819.exe When executed, it asks where to extract itself. This can be anywhere you like, but here we write the top directory for ntemacs as c:/pkg/ntemacs in the following. What follows is tested only on this version. Other versions may work but you have to figure out yourself how to use Unicode fonts on your version. 2. Install ucs-fonts and mule-fonts for emacs. Download from http://www.cl.cam.ac.uk/~mgk25/ucs-fonts.html the tar file http://www.cl.cam.ac.uk/~mgk25/download/ucs-fonts.tar.gz Let us write the top directory of extracted files as c:/pkg/ucs-fonts Next we create some derived fonts. cd c:/pkg/ucs-fonts/submission make all-bdfs This gives an error message about missing fonts, but ignore it. Download from http://www.meadowy.org/ the tar file http://www.meadowy.org/meadow/dists/3.00/packages/mule-fonts-1.0-4-pkg.tar.bz2 The untarred top directory is named "packages", but we are only interested in the subdirectory "packages/fonts". Let us assume we moved this subdirectory to c:/pkg/mule-fonts Add the following to your .emacs ;;;;;;;;; start of quoted elisp code (setq bdf-directory-list '( "c:/pkg/ucs-fonts/submission" "c:/pkg/mule-fonts/intlfonts" "c:/pkg/mule-fonts/efonts" "c:/pkg/mule-fonts/bitmap" "c:/pkg/mule-fonts/CDAC" "c:/pkg/mule-fonts/AkrutiFreeFonts" )) (setq w32-bdf-filename-alist (w32-find-bdf-fonts bdf-directory-list)) (create-fontset-from-fontset-spec "-*-fixed-Medium-r-Normal-*-15-*-*-*-c-*-fontset-bdf, ascii:-Misc-Fixed-Medium-R-Normal--15-140-75-75-C-90-ISO8859-1, latin-iso8859-2:-*-Fixed-*-r-*-*-15-*-*-*-c-*-iso8859-2, latin-iso8859-3:-*-Fixed-*-r-*-*-15-*-*-*-c-*-iso8859-3, latin-iso8859-4:-*-Fixed-*-r-*-*-15-*-*-*-c-*-iso8859-4, cyrillic-iso8859-5:-*-Fixed-*-r-*-*-15-*-*-*-c-*-iso8859-5, greek-iso8859-7:-*-Fixed-*-r-*-*-15-*-*-*-c-*-iso8859-7, latin-iso8859-9:-*-Fixed-*-r-*-*-15-*-*-*-c-*-iso8859-9, mule-unicode-0100-24ff:-Misc-Fixed-Medium-R-Normal--15-140-75-75-C-90-ISO10646-1, mule-unicode-2500-33ff:-Misc-Fixed-Medium-R-Normal--15-140-75-75-C-90-ISO10646-1, mule-unicode-e000-ffff:-Misc-Fixed-Medium-R-Normal--15-140-75-75-C-90-ISO10646-1, japanese-jisx0208:-JIS-Fixed-Medium-R-Normal--16-150-75-75-C-160-JISX0208.1983-0, japanese-jisx0208-1978:-Misc-Fixed-Medium-R-Normal--16-150-75-75-C-160-JISC6226.1978-0, japanese-jisx0212:-Misc-Fixed-Medium-R-Normal--16-150-75-75-C-160-JISX0212.1990-0, latin-jisx0201:-*-*-medium-r-normal-*-16-*-*-*-c-*-jisx0201*-*, katakana-jisx0201:-Sony-Fixed-Medium-R-Normal--16-120-100-100-C-80-JISX0201.1976-0, thai-tis620:-Misc-Fixed-Medium-R-Normal--24-240-72-72-C-120-TIS620.2529-1, lao:-Misc-Fixed-Medium-R-Normal--24-240-72-72-C-120-MuleLao-1, tibetan:-TibMdXA-fixed-medium-r-normal--16-160-72-72-m-160-MuleTibetan-0, tibetan-1-column:-TibMdXA-fixed-medium-r-normal--16-160-72-72-m-80-MuleTibetan-1, korean-ksc5601:-Daewoo-Mincho-Medium-R-Normal--16-120-100-100-C-160-KSC5601.1987-0, chinese-gb2312:-ISAS-Fangsong ti-Medium-R-Normal--16-160-72-72-c-160-GB2312.1980-0, chinese-cns11643-1:-HKU-Fixed-Medium-R-Normal--16-160-72-72-C-160-CNS11643.1992.1-0, chinese-big5-1:-ETen-Fixed-Medium-R-Normal--16-150-75-75-C-160-Big5.ETen-0, chinese-big5-2:-ETen-Fixed-Medium-R-Normal--16-150-75-75-C-160-Big5.ETen-0 " t) (setq font-encoding-alist (append '( ("JISX0208" (japanese-jisx0208 . 0)) ("JISX0212" (japanese-jisx0212 . 0)) ("CNS11643.1992.1-0" (chinese-cns11643-1 . 0)) ("GB2312" (chinese-gb2312 . 0)) ("KSC5601" (korean-ksc5601 . 0)) ("VISCII" (vietnamese-viscii-lower . 0)) ("MuleArabic-0" (arabic-digit . 0)) ("MuleArabic-1" (arabic-1-column . 0)) ("MuleArabic-2" (arabic-2-column . 0)) ("muleindian-1" (indian-1-column . 0)) ("muleindian-2" (indian-2-column . 0)) ("MuleTibetan-0" (tibetan . 0)) ("MuleTibetan-1" (tibetan-1-column . 0)) ) font-encoding-alist)) ;;;;;;; end of quoted elisp code To test the fonts, try M-x eval-expression RET (set-default-font "fontset-bdf") RET M-x view-hello-file You should see all the characters without white-boxes. Agda-2.3.2.2/.cvsignore0000644000000000000000000000024512221362553012702 0ustar0000000000000000_darcs .*.swp *~ out autom4te.cache configure config.status config.log tmp Agda2.tar.gz .DS_Store setup dist .setup-config .installed-pkg-config .inplace-pkg-config Agda-2.3.2.2/TODO0000644000000000000000000002010712221362553011371 0ustar0000000000000000 Features -------- * remembering the last thing in scope when computation gets stuck * debug information * Use substitutions for meta dependencies (at least for printing). We'll need to remember the number (or names?) of dependency args. How to show that a meta variable cannot depend on a particular variable? * lazy evaluation (or call by value?) * unify primitive and {-# BUILTIN #-} * allow module instantiation before top-level module(?) * abstract open (need to re-type check to make sure the abstraction is solid) * extend positivity check to handle function calls * mutual modules * more liberal builtin bindings (Nat as a special case of a general sequence) User interface -------------- * Highlighting fixity declarations and all module names. * Point warping for record fields. * locally nameless representation Fixes ----- [Errors] * DeclarationException when missing a type signature [Parsing] * allow more things in postulates (infix, private, ..) * allow fixity declarations for record fields (where?) * allow postulates in mutual * Check out lex/parse errors (what position and what input is reported). * Enable parsing of non-trivial literate files (see examples/syntax/highlighting/Test.lagda). [Serialisation] [Printing] * print patterns in mixfix notation (AbstractToConcrete) * meta variables are printed with their lambda lifted types [Scope] * check that fixity declarations correspond to actual definitions * change syntax for fixity declarations (infix is a bit strange for prefix and postfix operators) [Evaluation] * literal patterns are considered neutral when deciding if a match is No or DontKnow example funny : (A : Set) -> A -> D A -> .. funny .Nat zero nat funny .String "foo" string Here funny String "foo" string doesn't reduce because we DontKnow that "foo" doesn't match zero. [Type checking] * implicit function spaces and records interact badly with meta variables solution: postpone type checking problems - postpone checking of lambda against blocked types - postpone checking of applications where the function has a blocked type - postpone checking of records against blocked types [Testing] * write better tests [Bugs] * The Emacs interface meta variable treatment leads to problems with the syntax highlighting/point warping. Fix this by doing most work on the Haskell side, using the syntax tree, instead of mucking around with regular expressions on the Emacs side. Currently there are two known bugs: 1) _All_ question marks are treated as meta variables. 2) After a question mark has been converted into {! !} the point warping does not work (the offsets into the file have changed). * importing A after importing A.B causes a clash * Too many open files * Evaluation of _==_ loops on something like this: open module Eq = Equivalence (Eq'{ℂ}{A}{B}) renaming (_==_ to _=='_) f == g = .. ==' .. * There's a bug in the import chasing where a module can be imported before it's type checked. I.e. an old version of the module is stored in an interface file of a different module and we can't see that it's not up-do-date. I think this is what happens in the polydep example if everything is up-to-date except TYPE.agda. [Interaction] [Errors] * Remember/figure out range of previous binding in DuplicateBuiltinBinding. * wrong "When..." reported for f (g x) if g x is well-typed but of wrong type. * ranges of constructors in patterns are wrong. (also in right-hand sides?) * give sensible message for too few arguments to constructor in pattern [Type checking] * When do we have to turn on abstractMode. When checking anything public? Not done at the moment. [Imports] * handle clashing builtin things * create interface for top-level module (not so important) * allow the source to not exist if there is an interface file (what if it needs rebuilding? throw error) [Builtin] * check that bindings to list and bool binds to datatypes of the right shape [Misc] * Allow qualified names in BUILTIN pragma. Currently pragmas are parsed as plain strings, so a qualified name is interpreted as an unqualified name containing a dot. * check that the module name matches the file name. Also when importing the module name should be the one we're trying to import. * Allow modules to be called things like Prop and Set (?) * Move large parts of the Makefiles to mk/rules.mk (or something) Speculative ----------- * make scope checking aware of abstract? or maybe this is too much work Cleaning -------- * TypeChecking.Reduce - Explicit dictionaries (Kit)? see notes/kit * Split vim highlighting into a general highlighting module and the vim specific parts. Performance ----------- * Check what's taking time with new meta var/constraint handling * a lot of memory created by subst is never used * space leak in lexer (positions too lazy?) Done ---- * pattern coverage * with-clauses * better algorithm for pattern matching on inductive families * structured verbosity * records * implemented the CHIT-CHAT module system * polymorphic constructors at run-time (at least at conversion checking) * Split TypeChecking.Errors into TypeChecking.Pretty and TypeChecking.Errors * inductive families with pattern matching * build agda as a package to speed up loading into ghci * OpenTerm type to simplify deBruijn variable handling * Monad transformer for checking patterns. * pretty printing of operator applications * named implicit arguments, see notes/named-implicit * Use Data.ByteString (if ghc-6.6) for interface parsing (faster, but still quite slow) * optimized natural numbers, user view is still zero/suc. * allow reexporting of things using 'open Foo, public' * allow import and open before the top level module. * checking that underscores have been solved (only in batch mode) * syntax highlighting * proper make test (agda now exits with failure on error) * failing test (like in agdaLight) * throwing not-in-scope error rather than no parse for application wheneven possible * use interface files in scope checking * check for cyclic imports (we need to use interface files when scope checking) * removed list sugar (and made [ and ] valid in names) * create interface files when importing * allowing lambda-bound operators by always writing _+_ (hence making underscore in names carry semantics). * allow no type signatures for definitions of the form x = e * mix-fix operators * list sugar * handle absurd patterns * literal patterns * literals * built-in things * pragmas * move trace to environment * name suggestions in telescopes * forall x y z -> A = (x:_)(y:_)(z:_) -> A * cleaning up of TypeChecking.Monad.* * Context to abstract thinks that the types are valid in the entire context. * Hiding info on lambdas. * flag for printing all implicit arguments (handled in internal to abstract) * proof irrelevance * Prop <= Set * sort checking of datatypes check that all constructor arguments fit inside the datatype sort (rather than checking that the types of the constructor fit) * let-bindings (only x = e definitions) * insertion of hidden lambdas when appropriate * optimise * for an as-pattern x@p x should reduce to p during type checking * as-patterns * split TypeChecking.Monad.Context * better names for implicit args in lhs * replace explicit Hidden with Arg in Pi and App (and more?) * independent functions in Type * local functions * speed up normalise * getopts * When instantiating a module we should generate functions for the axioms and constructors and probably for everything else as well (reducing to the instantiated versions from the instantiated module). Together with monomorphic constructors. * Monomorphic constructors. * ? should not be a valid operator characted * actually check sorts * Get rid of distinction between hole and underscore. Instead keep a separate list of which metas are interaction points. * Blocked constructor in Terms and Types * insert hidden arguments in lhss * ranges in error messages * abstract info on constraints (TCEnv instead of Context) and interaction meta vars. vim: sts=2 sw=2 ts=80 Agda-2.3.2.2/doc/0000755000000000000000000000000012221362553011446 5ustar0000000000000000Agda-2.3.2.2/doc/pfe/0000755000000000000000000000000012221362553012220 5ustar0000000000000000Agda-2.3.2.2/doc/pfe/pfe.txt0000644000000000000000000000343712221362553013542 0ustar0000000000000000New try (again): # First make proper Haskell versions (not ghc-specific): make ALEX_FLAGS= OUT=../../doc/pfe/fake ../../doc/pfe/fake/Syntax/Parser/Lexer.hs make HAPPY_FLAGS=-a OUT=../../doc/pfe/fake ../../doc/pfe/fake/Syntax/Parser/Parser.hs # create missing file touch ../../doc/pfe/fake/Syntax/Parser/config.h # use hierarchical libraries (+h) # use the preprocessor # search in out and fake directories # chase modules from Main.hs pfesetup +h cpp -I../../doc/pfe/fake Main.hs pfe classmetrics # works pfe graph -dot Main > Main.dot # works pfe iface Main Now it works including "Analyzing", but not "Type checking": strange error in Hugs.Int: Unkown class: Num in Num Int8 Probably some ambiguity again? pfe dead works even longer but fails on deriving Data (should tell pfe that this is allowed) ~/src/programatica/tools/base/transforms/Deriving/Deriving.hs:43 proper addition is tiresome - possible to fake? ---- Everything below is older (newest try at the top) ------------------ New try: pfesetup cpp Main.hs pfe chase ../../out/full pfe chase hi/libs/HugsLibraries pfe chase . Same problem as before: ambiguous exports due to Hugs.Prelude also problems with Lexer and Parser ------- Older: Source files missing for (add files with 'pfe add' or 'pfe chase'): Data.Generics, needed by Syntax.Common Syntax.Concrete Syntax.Explanation Syntax.Internal Syntax.Position Data.Map, needed by Syntax.Concrete.Definitions Syntax.Scope added fakes finally no complaints of missing files __BUT__ lots of Ambiguous export entries instead (due to Hugs.Prelude) ---------------------------------------------------------------- pfesetup cpp Main.hs pfe chase /usr/local/lib/Programatica/libs/HugsLibraries Agda-2.3.2.2/doc/pfe/.cvsignore0000644000000000000000000000000712221362553014215 0ustar0000000000000000.*.swp Agda-2.3.2.2/doc/pfe/fake/0000755000000000000000000000000012221362553013126 5ustar0000000000000000Agda-2.3.2.2/doc/pfe/fake/Syntax/0000755000000000000000000000000012221362553014414 5ustar0000000000000000Agda-2.3.2.2/doc/pfe/fake/Syntax/Parser/0000755000000000000000000000000012221362553015650 5ustar0000000000000000Agda-2.3.2.2/doc/pfe/fake/Syntax/Parser/.cvsignore0000644000000000000000000000002312221362553017643 0ustar0000000000000000Parser.hs Lexer.hs Agda-2.3.2.2/doc/pfe/fake/Data/0000755000000000000000000000000012221362553013777 5ustar0000000000000000Agda-2.3.2.2/doc/pfe/fake/Data/Generics.hs0000644000000000000000000000060012221362553016066 0ustar0000000000000000module Data.Generics where -- | Parts of the ghc library Generics.hs -- | Fixity of constructors data Fixity = Prefix | Infix -- Later: add associativity and precedence deriving (Eq,Show) class Typeable a where typeOf :: a -> TypeRep class Typeable a => Data a where data TypeRep = Dummy dummy_declaration = True newtype GenericT' = GT { unGT :: a -> a } Agda-2.3.2.2/doc/pfe/fake/Data/Map.hs0000644000000000000000000000007312221362553015050 0ustar0000000000000000module Data.Map where dummy_declaration_in_Data_Map = True Agda-2.3.2.2/doc/haddock/0000755000000000000000000000000012221362553013043 5ustar0000000000000000Agda-2.3.2.2/doc/haddock/prologue0000644000000000000000000000006312221362553014621 0ustar0000000000000000The Agda II implementation. Haddock documentation. Agda-2.3.2.2/doc/haddock/Makefile0000644000000000000000000001022412221362553014502 0ustar0000000000000000# Making the haddock documentation # Author: Ulf Norell ## Includes ############################################################### TOP = ../.. include $(TOP)/mk/config.mk include $(TOP)/mk/paths.mk ## Variables ############################################################## # Haddock interface for the base package haddockURL = http://www.haskell.org/ghc/docs/$(GHC_VERSION)/html/libraries haddockArg = $(haddockURL)/$(1),$(1).haddock haddockFile = $(haddockURL)/$(1)/$(1).haddock # Haskell files lexer = Syntax/Parser/Lexer parser = Syntax/Parser/Parser gen_hs_files = $(FULL_OUT_DIR)/$(lexer).hs $(FULL_OUT_DIR)/$(parser).hs src_hs_files = $(shell $(FIND) $(FULL_SRC_DIR) -name '*.hs' -o -name '*.lhs') dst_hs_files = $(patsubst $(FULL_SRC_DIR)/%,src/%,$(src_hs_files)) \ $(patsubst $(FULL_OUT_DIR)/%,src/%,$(gen_hs_files)) # The prologue. Contains an introduction to the documentation prologue = prologue ## Phony targets ########################################################## .PHONY : default clean veryclean debug check_version ## Default target ######################################################### ifeq ($(HAVE_HADDOCK),Yes) default : index.html else default : @echo You need haddock to build this documentation. @$(FALSE) endif ## Base file ############################################################## ifeq ($(HAVE_WGET),Yes) %.haddock : wget $(call haddockFile,$*) else %.haddock : @echo $(call haddockFile,$*) have to be downloaded manually since wget could not be found. @$(FALSE) endif ## Preprocessing Haskell files ############################################ # Haddock cannot handle circular module dependencies or C preprocessor # directives in Haskell code, so we have to let ghc preprocess the source # files before giving them to haddock. To handle circular module # dependencies surround the boot file imports with an # #ifndef __HADDOCK__ # It might also be necessary to define a dummy version of types imported # from boot files as follows: # #ifndef __HADDOCK__ # import Foo (X) # #endif # ... # #ifdef __HADDOCK__ # -- | Trick to make haddock accept circular module dependencies. See 'Foo.X'. # data X # #endif # There is no need to do this for functions since they cannot appear in # types, and thus not in haddock documentation. src/% : $(FULL_SRC_DIR)/% src @echo Preprocessing $* for haddock @$(MKDIR) -p $(dir $@) @$(GHC) -E -optP-P -optP-I$(FULL_SRC_DIR) -D__HADDOCK__ -o $@ $< src/% : $(FULL_OUT_DIR)/% src @echo Preprocessing $* for haddock @$(MKDIR) -p $(dir $@) @$(GHC) -E -optP-P -optP-I$(FULL_SRC_DIR) -D__HADDOCK__ -o $@ $< src : $(MKDIR) -p src $(FULL_OUT_DIR)/$(parser).hs : $(FULL_SRC_DIR)/$(parser).y @$(MAKE) -C $(FULL_SRC_DIR) $@ $(FULL_OUT_DIR)/$(lexer).hs : $(FULL_SRC_DIR)/$(lexer).x @$(MAKE) -C $(FULL_SRC_DIR) $@ ## Building the haddock documentation ##################################### # It would be nice to check which version of haddock the ghc library # documentation is built with, but I don't know how (in an easy way). # For now it's hard-wired. ifeq ($(HAVE_GHC_6_4),Yes) base_interface_version = 0.7 else base_interface_version = 0.6 endif ifeq ($(HADDOCK_VERSION),$(base_interface_version)) check_version : else check_version : @echo "Warning: The ghc library documentation was probably" @echo " built using version $(base_interface_version) of haddock, but you" @echo " are using version $(HADDOCK_VERSION). Haddock might not be" @echo " able to link to library definitions." endif index.html : $(prologue) $(dst_hs_files) base.haddock mtl.haddock check_version $(HADDOCK) --odir=. --html \ --prologue=$(prologue) \ --title="Agda II Documentation" \ --ignore-all-exports \ --read-interface=$(call haddockArg,base) \ --read-interface=$(call haddockArg,mtl) \ $(dst_hs_files) ## Clean ################################################################## clean : rm -rf $(wildcard *.html) src haddock.css haskell_icon.gif veryclean : clean rm -f base.haddock ## Debugging the Makefile ################################################# debug : @echo The Haskell sources are @echo " $(src_hs_files)" @echo The preprocessed files are @echo " $(dst_hs_files)" Agda-2.3.2.2/doc/haddock/.cvsignore0000644000000000000000000000006012221362553015037 0ustar0000000000000000.*.swp *~ *.html *.css *.js *.gif *.haddock src Agda-2.3.2.2/doc/release-notes/0000755000000000000000000000000012221362553014214 5ustar0000000000000000Agda-2.3.2.2/doc/release-notes/2-2-10.txt0000644000000000000000000001702512221362553015500 0ustar0000000000000000------------------------------------------------------------------------ -- Release notes for Agda 2 version 2.2.10 ------------------------------------------------------------------------ Important changes since 2.2.8: Language -------- * New flag: --without-K. This flag makes pattern matching more restricted. If the flag is activated, then Agda only accepts certain case-splits. If the type of the variable to be split is D pars ixs, where D is a data (or record) type, pars stands for the parameters, and ixs the indices, then the following requirements must be satisfied: * The indices ixs must be applications of constructors to distinct variables. * These variables must not be free in pars. The intended purpose of --without-K is to enable experiments with a propositional equality without the K rule. Let us define propositional equality as follows: data _≡_ {A : Set} : A → A → Set where refl : ∀ x → x ≡ x Then the obvious implementation of the J rule is accepted: J : {A : Set} (P : {x y : A} → x ≡ y → Set) → (∀ x → P (refl x)) → ∀ {x y} (x≡y : x ≡ y) → P x≡y J P p (refl x) = p x The same applies to Christine Paulin-Mohring's version of the J rule: J′ : {A : Set} {x : A} (P : {y : A} → x ≡ y → Set) → P (refl x) → ∀ {y} (x≡y : x ≡ y) → P x≡y J′ P p (refl x) = p On the other hand, the obvious implementation of the K rule is not accepted: K : {A : Set} (P : {x : A} → x ≡ x → Set) → (∀ x → P (refl x)) → ∀ {x} (x≡x : x ≡ x) → P x≡x K P p (refl x) = p x However, we have /not/ proved that activation of --without-K ensures that the K rule cannot be proved in some other way. * Irrelevant declarations. Postulates and functions can be marked as irrelevant by prefixing the name with a dot when the name is declared. Example: postulate .irrelevant : {A : Set} → .A → A Irrelevant names may only be used in irrelevant positions or in definitions of things which have been declared irrelevant. The axiom irrelevant above can be used to define a projection from an irrelevant record field: data Subset (A : Set) (P : A → Set) : Set where _#_ : (a : A) → .(P a) → Subset A P elem : ∀ {A P} → Subset A P → A elem (a # p) = a .certificate : ∀ {A P} (x : Subset A P) → P (elem x) certificate (a # p) = irrelevant p The right-hand side of certificate is relevant, so we cannot define certificate (a # p) = p (because p is irrelevant). However, certificate is declared to be irrelevant, so it can use the axiom irrelevant. Furthermore the first argument of the axiom is irrelevant, which means that irrelevant p is well-formed. As shown above the axiom irrelevant justifies irrelevant projections. Previously no projections were generated for irrelevant record fields, such as the field certificate in the following record type: record Subset (A : Set) (P : A → Set) : Set where constructor _#_ field elem : A .certificate : P elem Now projections are generated automatically for irrelevant fields (unless the flag --no-irrelevant-projections is used). Note that irrelevant projections are highly experimental. * Termination checker recognises projections. Projections now preserve sizes, both in patterns and expressions. Example: record Wrap (A : Set) : Set where constructor wrap field unwrap : A open Wrap public data WNat : Set where zero : WNat suc : Wrap WNat → WNat id : WNat → WNat id zero = zero id (suc w) = suc (wrap (id (unwrap w))) In the structural ordering unwrap w ≤ w. This means that unwrap w ≤ w < suc w, and hence the recursive call to id is accepted. Projections also preserve guardedness. Tools ----- * Hyperlinks for top-level module names now point to the start of the module rather than to the declaration of the module name. This applies both to the Emacs mode and to the output of agda --html. * Most occurrences of record field names are now highlighted as "fields". Previously many occurrences were highlighted as "functions". * Emacs mode: It is no longer possible to change the behaviour of the TAB key by customising agda2-indentation. * Epic compiler backend. A new compiler backend is being implemented. This backend makes use of Edwin Brady's language Epic (http://www.cs.st-andrews.ac.uk/~eb/epic.php) and its compiler. The backend should handle most Agda code, but is still at an experimental stage: more testing is needed, and some things written below may not be entirely true. The Epic compiler can be invoked from the command line using the flag --epic: agda --epic --epic-flag= --compile-dir= .agda The --epic-flag flag can be given multiple times; each flag is given verbatim to the Epic compiler (in the given order). The resulting executable is named after the main module and placed in the directory specified by the --compile-dir flag (default: the project root). Intermediate files are placed in a subdirectory called Epic. The backend requires that there is a definition named main. This definition should be a value of type IO Unit, but at the moment this is not checked (so it is easy to produce a program which segfaults). Currently the backend represents actions of type IO A as functions from Unit to A, and main is applied to the unit value. The Epic compiler compiles via C, not Haskell, so the pragmas related to the Haskell FFI (IMPORT, COMPILED_DATA and COMPILED) are not used by the Epic backend. Instead there is a new pragma COMPILED_EPIC. This pragma is used to give Epic code for postulated definitions (Epic code can in turn call C code). The form of the pragma is {-# COMPILED_EPIC def code #-}, where def is the name of an Agda postulate and code is some Epic code which should include the function arguments, return type and function body. As an example the IO monad can be defined as follows: postulate IO : Set → Set return : ∀ {A} → A → IO A _>>=_ : ∀ {A B} → IO A → (A → IO B) → IO B {-# COMPILED_EPIC return (u : Unit, a : Any) -> Any = ioreturn(a) #-} {-# COMPILED_EPIC _>>=_ (u1 : Unit, u2 : Unit, x : Any, f : Any) -> Any = iobind(x,f) #-} Here ioreturn and iobind are Epic functions which are defined in the file AgdaPrelude.e which is always included. By default the backend will remove so-called forced constructor arguments (and case-splitting on forced variables will be rewritten). This optimisation can be disabled by using the flag --no-forcing. All data types which look like unary natural numbers after forced constructor arguments have been removed (i.e. types with two constructors, one nullary and one with a single recursive argument) will be represented as "BigInts". This applies to the standard Fin type, for instance. The backend supports Agda's primitive functions and the BUILTIN pragmas. If the BUILTIN pragmas for unary natural numbers are used, then some operations, like addition and multiplication, will use more efficient "BigInt" operations. If you want to make use of the Epic backend you need to install some dependencies, see the README. * The Emacs mode can compile using either the MAlonzo or the Epic backend. The variable agda2-backend controls which backend is used. Agda-2.3.2.2/doc/release-notes/2-3-0.txt0000644000000000000000000007702612221362553015427 0ustar0000000000000000------------------------------------------------------------------------ -- Release notes for Agda 2 version 2.3.0 ------------------------------------------------------------------------ Important changes since 2.2.10: Language ======== * New more liberal syntax for mutually recursive definitions. It is no longer necessary to use the 'mutual' keyword to define mutually recursive functions or datatypes. Instead, it is enough to declare things before they are used. Instead of mutual f : A f = a[f, g] g : B[f] g = b[f, g] you can now write f : A g : B[f] f = a[f, g] g = b[f, g]. With the new style you have more freedom in choosing the order in which things are type checked (previously type signatures were always checked before definitions). Furthermore you can mix arbitrary declarations, such as modules and postulates, with mutually recursive definitions. For data types and records the following new syntax is used to separate the declaration from the definition: -- Declaration. data Vec (A : Set) : Nat → Set -- Note the absence of 'where'. -- Definition. data Vec A where [] : Vec A zero _::_ : {n : Nat} → A → Vec A n → Vec A (suc n) -- Declaration. record Sigma (A : Set) (B : A → Set) : Set -- Definition. record Sigma A B where constructor _,_ field fst : A snd : B fst When making separated declarations/definitions private or abstract you should attach the 'private' keyword to the declaration and the 'abstract' keyword to the definition. For instance, a private, abstract function can be defined as private f : A abstract f = e Finally it may be worth noting that the old style of mutually recursive definitions is still supported (it basically desugars into the new style). * Pattern matching lambdas. Anonymous pattern matching functions can be defined using the syntax \ { p11 .. p1n -> e1 ; ... ; pm1 .. pmn -> em } (where, as usual, \ and -> can be replaced by λ and →). Internally this is translated into a function definition of the following form: .extlam p11 .. p1n = e1 ... .extlam pm1 .. pmn = em This means that anonymous pattern matching functions are generative. For instance, refl will not be accepted as an inhabitant of the type (λ { true → true ; false → false }) ≡ (λ { true → true ; false → false }), because this is equivalent to extlam1 ≡ extlam2 for some distinct fresh names extlam1 and extlam2. Currently the 'where' and 'with' constructions are not allowed in (the top-level clauses of) anonymous pattern matching functions. Examples: and : Bool → Bool → Bool and = λ { true x → x ; false _ → false } xor : Bool → Bool → Bool xor = λ { true true → false ; false false → false ; _ _ → true } fst : {A : Set} {B : A → Set} → Σ A B → A fst = λ { (a , b) → a } snd : {A : Set} {B : A → Set} (p : Σ A B) → B (fst p) snd = λ { (a , b) → b } * Record update syntax. Assume that we have a record type and a corresponding value: record MyRecord : Set where field a b c : ℕ old : MyRecord old = record { a = 1; b = 2; c = 3 } Then we can update (some of) the record value's fields in the following way: new : MyRecord new = record old { a = 0; c = 5 } Here new normalises to record { a = 0; b = 2; c = 5 }. Any expression yielding a value of type MyRecord can be used instead of old. Record updating is not allowed to change types: the resulting value must have the same type as the original one, including the record parameters. Thus, the type of a record update can be inferred if the type of the original record can be inferred. The record update syntax is expanded before type checking. When the expression record old { upd-fields } is checked against a record type R, it is expanded to let r = old in record { new-fields }, where old is required to have type R and new-fields is defined as follows: for each field x in R, - if x = e is contained in upd-fields then x = e is included in new-fields, and otherwise - if x is an explicit field then x = R.x r is included in new-fields, and - if x is an implicit or instance field, then it is omitted from new-fields. (Instance arguments are explained below.) The reason for treating implicit and instance fields specially is to allow code like the following: record R : Set where field {length} : ℕ vec : Vec ℕ length -- More fields… xs : R xs = record { vec = 0 ∷ 1 ∷ 2 ∷ [] } ys = record xs { vec = 0 ∷ [] } Without the special treatment the last expression would need to include a new binding for length (for instance "length = _"). * Record patterns which do not contain data type patterns, but which do contain dot patterns, are no longer rejected. * When the --without-K flag is used literals are now treated as constructors. * Under-applied functions can now reduce. Consider the following definition: id : {A : Set} → A → A id x = x Previously the expression id would not reduce. This has been changed so that it now reduces to λ x → x. Usually this makes little difference, but it can be important in conjunction with 'with'. See issue 365 for an example. * Unused AgdaLight legacy syntax (x y : A; z v : B) for telescopes has been removed. Universe polymorphism --------------------- * Universe polymorphism is now enabled by default. Use --no-universe-polymorphism to disable it. * Universe levels are no longer defined as a data type. The basic level combinators can be introduced in the following way: postulate Level : Set zero : Level suc : Level → Level max : Level → Level → Level {-# BUILTIN LEVEL Level #-} {-# BUILTIN LEVELZERO zero #-} {-# BUILTIN LEVELSUC suc #-} {-# BUILTIN LEVELMAX max #-} * The BUILTIN equality is now required to be universe-polymorphic. * trustMe is now universe-polymorphic. Meta-variables and unification ------------------------------ * Unsolved meta-variables are now frozen after every mutual block. This means that they cannot be instantiated by subsequent code. For instance, one : Nat one = _ bla : one ≡ suc zero bla = refl leads to an error now, whereas previously it lead to the instantiation of _ with "suc zero". If you want to make use of the old behaviour, put the two definitions in a mutual block. All meta-variables are unfrozen during interactive editing, so that the user can fill holes interactively. Note that type-checking of interactively given terms is not perfect: Agda sometimes refuses to load a file, even though no complaints were raised during the interactive construction of the file. This is because certain checks (for instance, positivity) are only invoked when a file is loaded. * Record types can now be inferred. If there is a unique known record type with fields matching the fields in a record expression, then the type of the expression will be inferred to be the record type applied to unknown parameters. If there is no known record type with the given fields the type checker will give an error instead of producing lots of unsolved meta-variables. Note that "known record type" refers to any record type in any imported module, not just types which are in scope. * The occurrence checker distinguishes rigid and strongly rigid occurrences [Reed, LFMTP 2009; Abel & Pientka, TLCA 2011]. The completeness checker now accepts the following code: h : (n : Nat) → n ≡ suc n → Nat h n () Internally this generates a constraint _n = suc _n where the meta-variable _n occurs strongly rigidly, i.e. on a constructor path from the root, in its own defining term tree. This is never solvable. Weakly rigid recursive occurrences may have a solution [Jason Reed's PhD thesis, page 106]: test : (k : Nat) → let X : (Nat → Nat) → Nat X = _ in (f : Nat → Nat) → X f ≡ suc (f (X (λ x → k))) test k f = refl The constraint _X k f = suc (f (_X k (λ x → k))) has the solution _X k f = suc (f (suc k)), despite the recursive occurrence of _X. Here _X is not strongly rigid, because it occurs under the bound variable f. Previously Agda rejected this code; now it instead complains about an unsolved meta-variable. * Equation constraints involving the same meta-variable in the head now trigger pruning [Pientka, PhD, Sec. 3.1.2; Abel & Pientka, TLCA 2011]. Example: same : let X : A → A → A → A × A X = _ in {x y z : A} → X x y y ≡ (x , y) × X x x y ≡ X x y y same = refl , refl The second equation implies that X cannot depend on its second argument. After pruning the first equation is linear and can be solved. * Instance arguments. A new type of hidden function arguments has been added: instance arguments. This new feature is based on influences from Scala's implicits and Agda's existing implicit arguments. Plain implicit arguments are marked by single braces: {…}. Instance arguments are instead marked by double braces: {{…}}. Example: postulate A : Set B : A → Set a : A f : {{a : A}} → B a Instead of the double braces you can use the symbols ⦃ and ⦄, but these symbols must in many cases be surrounded by whitespace. (If you are using Emacs and the Agda input method, then you can conjure up the symbols by typing "\{{" and "\}}", respectively.) Instance arguments behave as ordinary implicit arguments, except for one important aspect: resolution of arguments which are not provided explicitly. For instance, consider the following code: test = f Here Agda will notice that f's instance argument was not provided explicitly, and try to infer it. All definitions in scope at f's call site, as well as all variables in the context, are considered. If exactly one of these names has the required type (A), then the instance argument will be instantiated to this name. This feature can be used as an alternative to Haskell type classes. If we define record Eq (A : Set) : Set where field equal : A → A → Bool, then we can define the following projection: equal : {A : Set} {{eq : Eq A}} → A → A → Bool equal {{eq}} = Eq.equal eq Now consider the following expression: equal false false ∨ equal 3 4 If the following Eq "instances" for Bool and ℕ are in scope, and no others, then the expression is accepted: eq-Bool : Eq Bool eq-Bool = record { equal = … } eq-ℕ : Eq ℕ eq-ℕ = record { equal = … } A shorthand notation is provided to avoid the need to define projection functions manually: module Eq-with-implicits = Eq {{...}} This notation creates a variant of Eq's record module, where the main Eq argument is an instance argument instead of an explicit one. It is equivalent to the following definition: module Eq-with-implicits {A : Set} {{eq : Eq A}} = Eq eq Note that the short-hand notation allows you to avoid naming the "-with-implicits" module: open Eq {{...}} Instance argument resolution is not recursive. As an example, consider the following "parametrised instance": eq-List : {A : Set} → Eq A → Eq (List A) eq-List {A} eq = record { equal = eq-List-A } where eq-List-A : List A → List A → Bool eq-List-A [] [] = true eq-List-A (a ∷ as) (b ∷ bs) = equal a b ∧ eq-List-A as bs eq-List-A _ _ = false Assume that the only Eq instances in scope are eq-List and eq-ℕ. Then the following code does not type-check: test = equal (1 ∷ 2 ∷ []) (3 ∷ 4 ∷ []) However, we can make the code work by constructing a suitable instance manually: test′ = equal (1 ∷ 2 ∷ []) (3 ∷ 4 ∷ []) where eq-List-ℕ = eq-List eq-ℕ By restricting the "instance search" to be non-recursive we avoid introducing a new, compile-time-only evaluation model to Agda. For more information about instance arguments, see Devriese & Piessens [ICFP 2011]. Some examples are also available in the examples/instance-arguments subdirectory of the Agda distribution. Irrelevance ----------- * Dependent irrelevant function types. Some examples illustrating the syntax of dependent irrelevant function types: .(x y : A) → B .{x y z : A} → B ∀ x .y → B ∀ x .{y} {z} .v → B The declaration f : .(x : A) → B[x] f x = t[x] requires that x is irrelevant both in t[x] and in B[x]. This is possible if, for instance, B[x] = B′ x, with B′ : .A → Set. Dependent irrelevance allows us to define the eliminator for the Squash type: record Squash (A : Set) : Set where constructor squash field .proof : A elim-Squash : {A : Set} (P : Squash A → Set) (ih : .(a : A) → P (squash a)) → (a⁻ : Squash A) → P a⁻ elim-Squash P ih (squash a) = ih a Note that this would not type-check with (ih : (a : A) -> P (squash a)). * Records with only irrelevant fields. The following now works: record IsEquivalence {A : Set} (_≈_ : A → A → Set) : Set where field .refl : Reflexive _≈_ .sym : Symmetric _≈_ .trans : Transitive _≈_ record Setoid : Set₁ where infix 4 _≈_ field Carrier : Set _≈_ : Carrier → Carrier → Set .isEquivalence : IsEquivalence _≈_ open IsEquivalence isEquivalence public Previously Agda complained about the application IsEquivalence isEquivalence, because isEquivalence is irrelevant and the IsEquivalence module expected a relevant argument. Now, when record modules are generated for records consisting solely of irrelevant arguments, the record parameter is made irrelevant: module IsEquivalence {A : Set} {_≈_ : A → A → Set} .(r : IsEquivalence {A = A} _≈_) where … * Irrelevant things are no longer erased internally. This means that they are printed as ordinary terms, not as "_" as before. * The new flag --experimental-irrelevance enables irrelevant universe levels and matching on irrelevant data when only one constructor is available. These features are very experimental and likely to change or disappear. Reflection ---------- * The reflection API has been extended to mirror features like irrelevance, instance arguments and universe polymorphism, and to give (limited) access to definitions. For completeness all the builtins and primitives are listed below: -- Names. postulate Name : Set {-# BUILTIN QNAME Name #-} primitive -- Equality of names. primQNameEquality : Name → Name → Bool -- Is the argument visible (explicit), hidden (implicit), or an -- instance argument? data Visibility : Set where visible hidden instance : Visibility {-# BUILTIN HIDING Visibility #-} {-# BUILTIN VISIBLE visible #-} {-# BUILTIN HIDDEN hidden #-} {-# BUILTIN INSTANCE instance #-} -- Arguments can be relevant or irrelevant. data Relevance : Set where relevant irrelevant : Relevance {-# BUILTIN RELEVANCE Relevance #-} {-# BUILTIN RELEVANT relevant #-} {-# BUILTIN IRRELEVANT irrelevant #-} -- Arguments. data Arg A : Set where arg : (v : Visibility) (r : Relevance) (x : A) → Arg A {-# BUILTIN ARG Arg #-} {-# BUILTIN ARGARG arg #-} -- Terms. mutual data Term : Set where -- Variable applied to arguments. var : (x : ℕ) (args : List (Arg Term)) → Term -- Constructor applied to arguments. con : (c : Name) (args : List (Arg Term)) → Term -- Identifier applied to arguments. def : (f : Name) (args : List (Arg Term)) → Term -- Different kinds of λ-abstraction. lam : (v : Visibility) (t : Term) → Term -- Pi-type. pi : (t₁ : Arg Type) (t₂ : Type) → Term -- A sort. sort : Sort → Term -- Anything else. unknown : Term data Type : Set where el : (s : Sort) (t : Term) → Type data Sort : Set where -- A Set of a given (possibly neutral) level. set : (t : Term) → Sort -- A Set of a given concrete level. lit : (n : ℕ) → Sort -- Anything else. unknown : Sort {-# BUILTIN AGDASORT Sort #-} {-# BUILTIN AGDATYPE Type #-} {-# BUILTIN AGDATERM Term #-} {-# BUILTIN AGDATERMVAR var #-} {-# BUILTIN AGDATERMCON con #-} {-# BUILTIN AGDATERMDEF def #-} {-# BUILTIN AGDATERMLAM lam #-} {-# BUILTIN AGDATERMPI pi #-} {-# BUILTIN AGDATERMSORT sort #-} {-# BUILTIN AGDATERMUNSUPPORTED unknown #-} {-# BUILTIN AGDATYPEEL el #-} {-# BUILTIN AGDASORTSET set #-} {-# BUILTIN AGDASORTLIT lit #-} {-# BUILTIN AGDASORTUNSUPPORTED unknown #-} postulate -- Function definition. Function : Set -- Data type definition. Data-type : Set -- Record type definition. Record : Set {-# BUILTIN AGDAFUNDEF Function #-} {-# BUILTIN AGDADATADEF Data-type #-} {-# BUILTIN AGDARECORDDEF Record #-} -- Definitions. data Definition : Set where function : Function → Definition data-type : Data-type → Definition record′ : Record → Definition constructor′ : Definition axiom : Definition primitive′ : Definition {-# BUILTIN AGDADEFINITION Definition #-} {-# BUILTIN AGDADEFINITIONFUNDEF function #-} {-# BUILTIN AGDADEFINITIONDATADEF data-type #-} {-# BUILTIN AGDADEFINITIONRECORDDEF record′ #-} {-# BUILTIN AGDADEFINITIONDATACONSTRUCTOR constructor′ #-} {-# BUILTIN AGDADEFINITIONPOSTULATE axiom #-} {-# BUILTIN AGDADEFINITIONPRIMITIVE primitive′ #-} primitive -- The type of the thing with the given name. primQNameType : Name → Type -- The definition of the thing with the given name. primQNameDefinition : Name → Definition -- The constructors of the given data type. primDataConstructors : Data-type → List Name As an example the expression primQNameType (quote zero) is definitionally equal to el (lit 0) (def (quote ℕ) []) (if zero is a constructor of the data type ℕ). * New keyword: unquote. The construction "unquote t" converts a representation of an Agda term to actual Agda code in the following way: 1. The argument t must have type Term (see the reflection API above). 2. The argument is normalised. 3. The entire construction is replaced by the normal form, which is treated as syntax written by the user and type-checked in the usual way. Examples: test : unquote (def (quote ℕ) []) ≡ ℕ test = refl id : (A : Set) → A → A id = unquote (lam visible (lam visible (var 0 []))) id-ok : id ≡ (λ A (x : A) → x) id-ok = refl * New keyword: quoteTerm. The construction "quoteTerm t" is similar to "quote n", but whereas quote is restricted to names n, quoteTerm accepts terms t. The construction is handled in the following way: 1. The type of t is inferred. The term t must be type-correct. 2. The term t is normalised. 3. The construction is replaced by the Term representation (see the reflection API above) of the normal form. Any unsolved metavariables in the term are represented by the "unknown" term constructor. Examples: test₁ : quoteTerm (λ {A : Set} (x : A) → x) ≡ lam hidden (lam visible (var 0 [])) test₁ = refl -- Local variables are represented as de Bruijn indices. test₂ : (λ {A : Set} (x : A) → quoteTerm x) ≡ (λ x → var 0 []) test₂ = refl -- Terms are normalised before being quoted. test₃ : quoteTerm (0 + 0) ≡ con (quote zero) [] test₃ = refl Compiler backends ================= MAlonzo ------- * The MAlonzo backend's FFI now handles universe polymorphism in a better way. The translation of Agda types and kinds into Haskell now supports universe-polymorphic postulates. The core changes are that the translation of function types has been changed from T[[ Pi (x : A) B ]] = if A has a Haskell kind then forall x. () -> T[[ B ]] else if x in fv B then undef else T[[ A ]] -> T[[ B ]] into T[[ Pi (x : A) B ]] = if x in fv B then forall x. T[[ A ]] -> T[[ B ]] -- Note: T[[A]] not Unit. else T[[ A ]] -> T[[ B ]], and that the translation of constants (postulates, constructors and literals) has been changed from T[[ k As ]] = if COMPILED_TYPE k T then T T[[ As ]] else undef into T[[ k As ]] = if COMPILED_TYPE k T then T T[[ As ]] else if COMPILED k E then () else undef. For instance, assuming a Haskell definition type AgdaIO a b = IO b, we can set up universe-polymorphic IO in the following way: postulate IO : ∀ {ℓ} → Set ℓ → Set ℓ return : ∀ {a} {A : Set a} → A → IO A _>>=_ : ∀ {a b} {A : Set a} {B : Set b} → IO A → (A → IO B) → IO B {-# COMPILED_TYPE IO AgdaIO #-} {-# COMPILED return (\_ _ -> return) #-} {-# COMPILED _>>=_ (\_ _ _ _ -> (>>=)) #-} This is accepted because (assuming that the universe level type is translated to the Haskell unit type "()") (\_ _ -> return) : forall a. () -> forall b. () -> b -> AgdaIO a b = T [[ ∀ {a} {A : Set a} → A → IO A ]] and (\_ _ _ _ -> (>>=)) : forall a. () -> forall b. () -> forall c. () -> forall d. () -> AgdaIO a c -> (c -> AgdaIO b d) -> AgdaIO b d = T [[ ∀ {a b} {A : Set a} {B : Set b} → IO A → (A → IO B) → IO B ]]. Epic ---- * New Epic backend pragma: STATIC. In the Epic backend, functions marked with the STATIC pragma will be normalised before compilation. Example usage: {-# STATIC power #-} power : ℕ → ℕ → ℕ power 0 x = 1 power 1 x = x power (suc n) x = power n x * x Occurrences of "power 4 x" will be replaced by "((x * x) * x) * x". * Some new optimisations have been implemented in the Epic backend: - Removal of unused arguments. A worker/wrapper transformation is performed so that unused arguments can be removed by Epic's inliner. For instance, the map function is transformed in the following way: map_wrap : (A B : Set) → (A → B) → List A → List B map_wrap A B f xs = map_work f xs map_work f [] = [] map_work f (x ∷ xs) = f x ∷ map_work f xs If map_wrap is inlined (which it will be in any saturated call), then A and B disappear in the generated code. Unused arguments are found using abstract interpretation. The bodies of all functions in a module are inspected to decide which variables are used. The behaviour of postulates is approximated based on their types. Consider return, for instance: postulate return : {A : Set} → A → IO A The first argument of return can be removed, because it is of type Set and thus cannot affect the outcome of a program at runtime. - Injection detection. At runtime many functions may turn out to be inefficient variants of the identity function. This is especially true after forcing. Injection detection replaces some of these functions with more efficient versions. Example: inject : {n : ℕ} → Fin n → Fin (1 + n) inject {suc n} zero = zero inject {suc n} (suc i) = suc (inject {n} i) Forcing removes the Fin constructors' ℕ arguments, so this function is an inefficient identity function that can be replaced by the following one: inject {_} x = x To actually find this function, we make the induction hypothesis that inject is an identity function in its second argument and look at the branches of the function to decide if this holds. Injection detection also works over data type barriers. Example: forget : {A : Set} {n : ℕ} → Vec A n → List A forget [] = [] forget (x ∷ xs) = x ∷ forget xs Given that the constructor tags (in the compiled Epic code) for Vec.[] and List.[] are the same, and that the tags for Vec._∷_ and List._∷_ are also the same, this is also an identity function. We can hence replace the definition with the following one: forget {_} xs = xs To get this to apply as often as possible, constructor tags are chosen /after/ injection detection has been run, in a way to make as many functions as possible injections. Constructor tags are chosen once per source file, so it may be advantageous to define conversion functions like forget in the same module as one of the data types. For instance, if Vec.agda imports List.agda, then the forget function should be put in Vec.agda to ensure that vectors and lists get the same tags (unless some other injection function, which puts different constraints on the tags, is prioritised). - Smashing. This optimisation finds types whose values are inferable at runtime: * A data type with only one constructor where all fields are inferable is itself inferable. * Set ℓ is inferable (as it has no runtime representation). A function returning an inferable data type can be smashed, which means that it is replaced by a function which simply returns the inferred value. An important example of an inferable type is the usual propositional equality type (_≡_). Any function returning a propositional equality can simply return the reflexivity constructor directly without computing anything. This optimisation makes more arguments unused. It also makes the Epic code size smaller, which in turn speeds up compilation. JavaScript ---------- * ECMAScript compiler backend. A new compiler backend is being implemented, targetting ECMAScript (also known as JavaScript), with the goal of allowing Agda programs to be run in browsers or other ECMAScript environments. The backend is still at an experimental stage: the core language is implemented, but many features are still missing. The ECMAScript compiler can be invoked from the command line using the flag --js: agda --js --compile-dir= .agda Each source .agda is compiled into an ECMAScript target /jAgda..js. The compiler can also be invoked using the Emacs mode (the variable agda2-backend controls which backend is used). Note that ECMAScript is a strict rather than lazy language. Since Agda programs are total, this should not impact program semantics, but it may impact their space or time usage. ECMAScript does not support algebraic datatypes or pattern-matching. These features are translated to a use of the visitor pattern. For instance, the standard library's List data type and null function are translated into the following code: exports["List"] = {}; exports["List"]["[]"] = function (x0) { return x0["[]"](); }; exports["List"]["_∷_"] = function (x0) { return function (x1) { return function (x2) { return x2["_∷_"](x0, x1); }; }; }; exports["null"] = function (x0) { return function (x1) { return function (x2) { return x2({ "[]": function () { return jAgda_Data_Bool["Bool"]["true"]; }, "_∷_": function (x3, x4) { return jAgda_Data_Bool["Bool"]["false"]; } }); }; }; }; Agda records are translated to ECMAScript objects, preserving field names. Top-level Agda modules are translated to ECMAScript modules, following the common.js module specification. A top-level Agda module "Foo.Bar" is translated to an ECMAScript module "jAgda.Foo.Bar". The ECMAScript compiler does not compile to Haskell, so the pragmas related to the Haskell FFI (IMPORT, COMPILED_DATA and COMPILED) are not used by the ECMAScript backend. Instead, there is a COMPILED_JS pragma which may be applied to any declaration. For postulates, primitives, functions and values, it gives the ECMAScript code to be emitted by the compiler. For data types, it gives a function which is applied to a value of that type, and a visitor object. For instance, a binding of natural numbers to ECMAScript integers (ignoring overflow errors) is: data ℕ : Set where zero : ℕ suc : ℕ → ℕ {-# COMPILED_JS ℕ function (x,v) { if (x < 1) { return v.zero(); } else { return v.suc(x-1); } } #-} {-# COMPILED_JS zero 0 #-} {-# COMPILED_JS suc function (x) { return x+1; } #-} _+_ : ℕ → ℕ → ℕ zero + n = n suc m + n = suc (m + n) {-# COMPILED_JS _+_ function (x) { return function (y) { return x+y; }; } #-} To allow FFI code to be optimised, the ECMAScript in a COMPILED_JS declaration is parsed, using a simple parser that recognises a pure functional subset of ECMAScript, consisting of functions, function applications, return, if-statements, if-expressions, side-effect-free binary operators (no precedence, left associative), side-effect-free prefix operators, objects (where all member names are quoted), field accesses, and string and integer literals. Modules may be imported using the require("") syntax: any impure code, or code outside the supported fragment, can be placed in a module and imported. Tools ===== * New flag --safe, which can be used to type-check untrusted code. This flag disables postulates, primTrustMe, and "unsafe" OPTION pragmas, some of which are known to make Agda inconsistent. Rejected pragmas: --allow-unsolved-metas --experimental-irrelevance --guardedness-preserving-type-construtors --injective-type-constructors --no-coverage-check --no-positivity-check --no-termination-check --sized-types --type-in-type Note that, at the moment, it is not possible to define the universe level or coinduction primitives when --safe is used (because they must be introduced as postulates). This can be worked around by type-checking trusted files in a first pass, without using --safe, and then using --safe in a second pass. Modules which have already been type-checked are not re-type-checked just because --safe is used. * Dependency graphs. The new flag --dependency-graph=FILE can be used to generate a DOT file containing a module dependency graph. The generated file (FILE) can be rendered using a tool like dot. * The --no-unreachable-check flag has been removed. * Projection functions are highlighted as functions instead of as fields. Field names (in record definitions and record values) are still highlighted as fields. * Support for jumping to positions mentioned in the information buffer has been added. * The "make install" command no longer installs Agda globally (by default). Agda-2.3.2.2/doc/release-notes/2-2-6.txt0000644000000000000000000002062112221362553015421 0ustar0000000000000000------------------------------------------------------------------------ -- Release notes for Agda 2 version 2.2.6 ------------------------------------------------------------------------ Important changes since 2.2.4: Language -------- * Universe polymorphism (experimental extension). To enable universe polymorphism give the flag --universe-polymorphism on the command line or (recommended) as an OPTIONS pragma. When universe polymorphism is enabled Set takes an argument which is the universe level. For instance, the type of universe polymorphic identity is id : {a : Level} {A : Set a} → A → A. The type Level is isomorphic to the unary natural numbers and should be specified using the BUILTINs LEVEL, LEVELZERO, and LEVELSUC: data Level : Set where zero : Level suc : Level → Level {-# BUILTIN LEVEL Level #-} {-# BUILTIN LEVELZERO zero #-} {-# BUILTIN LEVELSUC suc #-} There is an additional BUILTIN LEVELMAX for taking the maximum of two levels: max : Level → Level → Level max zero m = m max (suc n) zero = suc n max (suc n) (suc m) = suc (max n m) {-# BUILTIN LEVELMAX max #-} The non-polymorphic universe levels Set, Set₁ and so on are sugar for Set zero, Set (suc zero), etc. At present there is no automatic lifting of types from one level to another. It can still be done (rather clumsily) by defining types like the following one: data Lifted {a} (A : Set a) : Set (suc a) where lift : A → Lifted A However, it is likely that automatic lifting is introduced at some point in the future. * Multiple constructors, record fields, postulates or primitives can be declared using a single type signature: data Bool : Set where false true : Bool postulate A B : Set * Record fields can be implicit: record R : Set₁ where field {A} : Set f : A → A {B C} D {E} : Set g : B → C → E By default implicit fields are not printed. * Record constructors can be defined: record Σ (A : Set) (B : A → Set) : Set where constructor _,_ field proj₁ : A proj₂ : B proj₁ In this example _,_ gets the type (proj₁ : A) → B proj₁ → Σ A B. For implicit fields the corresponding constructor arguments become implicit. Note that the constructor is defined in the /outer/ scope, so any fixity declaration has to be given outside the record definition. The constructor is not in scope inside the record module. Note also that pattern matching for records has not been implemented yet. * BUILTIN hooks for equality. The data type data _≡_ {A : Set} (x : A) : A → Set where refl : x ≡ x can be specified as the builtin equality type using the following pragmas: {-# BUILTIN EQUALITY _≡_ #-} {-# BUILTIN REFL refl #-} The builtin equality is used for the new rewrite construct and the primTrustMe primitive described below. * New rewrite construct. If eqn : a ≡ b, where _≡_ is the builtin equality (see above) you can now write f ps rewrite eqn = rhs instead of f ps with a | eqn ... | ._ | refl = rhs The rewrite construct has the effect of rewriting the goal and the context by the given equation (left to right). You can rewrite using several equations (in sequence) by separating them with vertical bars (|): f ps rewrite eqn₁ | eqn₂ | … = rhs It is also possible to add with clauses after rewriting: f ps rewrite eqns with e ... | p = rhs Note that pattern matching happens before rewriting—if you want to rewrite and then do pattern matching you can use a with after the rewrite. See test/succeed/Rewrite.agda for some examples. * A new primitive, primTrustMe, has been added: primTrustMe : {A : Set} {x y : A} → x ≡ y Here _≡_ is the builtin equality (see BUILTIN hooks for equality, above). If x and y are definitionally equal, then primTrustMe {x = x} {y = y} reduces to refl. Note that the compiler replaces all uses of primTrustMe with the REFL builtin, without any check for definitional equality. Incorrect uses of primTrustMe can potentially lead to segfaults or similar problems. For an example of the use of primTrustMe, see Data.String in version 0.3 of the standard library, where it is used to implement decidable equality on strings using the primitive boolean equality. * Changes to the syntax and semantics of IMPORT pragmas, which are used by the Haskell FFI. Such pragmas must now have the following form: {-# IMPORT #-} These pragmas are interpreted as /qualified/ imports, so Haskell names need to be given qualified (unless they come from the Haskell prelude). * The horizontal tab character (U+0009) is no longer treated as white space. * Line pragmas are no longer supported. * The --include-path flag can no longer be used as a pragma. * The experimental and incomplete support for proof irrelevance has been disabled. Tools ----- * New "intro" command in the Emacs mode. When there is a canonical way of building something of the goal type (for instance, if the goal type is a pair), the goal can be refined in this way. The command works for the following goal types: - A data type where only one of its constructors can be used to construct an element of the goal type. (For instance, if the goal is a non-empty vector, a "cons" will be introduced.) - A record type. A record value will be introduced. Implicit fields will not be included unless showing of implicit arguments is switched on. - A function type. A lambda binding as many variables as possible will be introduced. The variable names will be chosen from the goal type if its normal form is a dependent function type, otherwise they will be variations on "x". Implicit lambdas will only be inserted if showing of implicit arguments is switched on. This command can be invoked by using the refine command (C-c C-r) when the goal is empty. (The old behaviour of the refine command in this situation was to ask for an expression using the minibuffer.) * The Emacs mode displays "Checked" in the mode line if the current file type checked successfully without any warnings. * If a file F is loaded, and this file defines the module M, it is an error if F is not the file which defines M according to the include path. Note that the command-line tool and the Emacs mode define the meaning of relative include paths differently: the command-line tool interprets them relative to the current working directory, whereas the Emacs mode interprets them relative to the root directory of the current project. (As an example, if the module A.B.C is loaded from the file /A/B/C.agda, then the root directory is .) * It is an error if there are several files on the include path which match a given module name. * Interface files are relocatable. You can move around source trees as long as the include path is updated in a corresponding way. Note that a module M may be re-typechecked if its time stamp is strictly newer than that of the corresponding interface file (M.agdai). * Type-checking is no longer done when an up-to-date interface exists. (Previously the initial module was always type-checked.) * Syntax highlighting files for Emacs (.agda.el) are no longer used. The --emacs flag has been removed. (Syntax highlighting information is cached in the interface files.) * The Agate and Alonzo compilers have been retired. The options --agate, --alonzo and --malonzo have been removed. * The default directory for MAlonzo output is the project's root directory. The --malonzo-dir flag has been renamed to --compile-dir. * Emacs mode: C-c C-x C-d no longer resets the type checking state. C-c C-x C-r can be used for a more complete reset. C-c C-x C-s (which used to reload the syntax highlighting information) has been removed. C-c C-l can be used instead. * The Emacs mode used to define some "abbrevs", unless the user explicitly turned this feature off. The new default is /not/ to add any abbrevs. The old default can be obtained by customising agda2-mode-abbrevs-use-defaults (a customisation buffer can be obtained by typing M-x customize-group agda2 RET after an Agda file has been loaded). Agda-2.3.2.2/doc/release-notes/2-2-4.txt0000644000000000000000000000265112221362553015422 0ustar0000000000000000------------------------------------------------------------------------ -- Release notes for Agda 2 version 2.2.4 ------------------------------------------------------------------------ Important changes since 2.2.2: * Change to the semantics of "open import" and "open module". The declaration open import M now translates to import A open A instead of import A open A. The same translation is used for "open module M = E …". Declarations involving the keywords as or public are changed in a corresponding way ("as" always goes with import, and "public" always with open). This change means that import directives do not affect the qualified names when open import/module is used. To get the old behaviour you can use the expanded version above. * Names opened publicly in parameterised modules no longer inherit the module parameters. Example: module A where postulate X : Set module B (Y : Set) where open A public In Agda 2.2.2 B.X has type (Y : Set) → Set, whereas in Agda 2.2.4 B.X has type Set. * Previously it was not possible to export a given constructor name through two different "open public" statements in the same module. This is now possible. * Unicode subscript digits are now allowed for the hierarchy of universes (Set₀, Set₁, …): Set₁ is equivalent to Set1. Agda-2.3.2.2/doc/release-notes/2-2-0.txt0000644000000000000000000000571512221362553015422 0ustar0000000000000000------------------------------------------------------------------------ -- Release notes for Agda 2 version 2.2.0 ------------------------------------------------------------------------ Important changes since 2.1.2 (which was released 2007-08-16): Language -------- * Exhaustive pattern checking. Agda complains if there are missing clauses in a function definition. * Coinductive types are supported. This feature is under development/evaluation, and may change. http://wiki.portal.chalmers.se/agda/agda.php?n=ReferenceManual.Codatatypes * Another experimental feature: Sized types, which can make it easier to explain why your code is terminating. * Improved constraint solving for functions with constructor headed right hand sides. http://wiki.portal.chalmers.se/agda/agda.php?n=ReferenceManual.FindingTheValuesOfImplicitArguments * A simple, well-typed foreign function interface, which allows use of Haskell functions in Agda code. http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Docs.FFI * The tokens forall, -> and \ can be written as ∀, → and λ. * Absurd lambdas: λ () and λ {}. http://thread.gmane.org/gmane.comp.lang.agda/440 * Record fields whose values can be inferred can be omitted. * Agda complains if it spots an unreachable clause, or if a pattern variable "shadows" a hidden constructor of matching type. http://thread.gmane.org/gmane.comp.lang.agda/720 Tools ----- * Case-split: The user interface can replace a pattern variable with the corresponding constructor patterns. You get one new left-hand side for every possible constructor. http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Main.QuickGuideToEditingTypeCheckingAndCompilingAgdaCode * The MAlonzo compiler. http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Docs.MAlonzo * A new Emacs input method, which contains bindings for many Unicode symbols, is by default activated in the Emacs mode. http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Docs.UnicodeInput * Highlighted, hyperlinked HTML can be generated from Agda source code. http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Main.HowToGenerateWebPagesFromSourceCode * The command-line interactive mode (agda -I) is no longer supported, but should still work. http://thread.gmane.org/gmane.comp.lang.agda/245 * Reload times when working on large projects are now considerably better. http://thread.gmane.org/gmane.comp.lang.agda/551 Libraries --------- * A standard library is under development. http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Libraries.StandardLibrary Documentation ------------- * The Agda wiki is better organised. It should be easier for a newcomer to find relevant information now. http://wiki.portal.chalmers.se/agda/ Infrastructure -------------- * Easy-to-install packages for Windows and Debian/Ubuntu have been prepared. http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Main.Download * Agda 2.2.0 is available from Hackage. http://hackage.haskell.org/ Agda-2.3.2.2/doc/release-notes/2-3-2-2.txt0000644000000000000000000000056712221362553015564 0ustar0000000000000000------------------------------------------------------------------------ -- Release notes for Agda 2 version 2.3.2.2 ------------------------------------------------------------------------ Important changes since 2.3.2.1: * Fixed a bug that sometimes made it tricky to use the Emacs mode on Windows [issue 757]. * Made Agda build with newer versions of some libraries. Agda-2.3.2.2/doc/release-notes/2-2-8.txt0000644000000000000000000004347512221362553015437 0ustar0000000000000000------------------------------------------------------------------------ -- Release notes for Agda 2 version 2.2.8 ------------------------------------------------------------------------ Important changes since 2.2.6: Language -------- * Record pattern matching. It is now possible to pattern match on named record constructors. Example: record Σ (A : Set) (B : A → Set) : Set where constructor _,_ field proj₁ : A proj₂ : B proj₁ map : {A B : Set} {P : A → Set} {Q : B → Set} (f : A → B) → (∀ {x} → P x → Q (f x)) → Σ A P → Σ B Q map f g (x , y) = (f x , g y) The clause above is internally translated into the following one: map f g p = (f (Σ.proj₁ p) , g (Σ.proj₂ p)) Record patterns containing data type patterns are not translated. Example: add : ℕ × ℕ → ℕ add (zero , n) = n add (suc m , n) = suc (add (m , n)) Record patterns which do not contain data type patterns, but which do contain dot patterns, are currently rejected. Example: Foo : {A : Set} (p₁ p₂ : A × A) → proj₁ p₁ ≡ proj₁ p₂ → Set₁ Foo (x , y) (.x , y′) refl = Set * Proof irrelevant function types. Agda now supports irrelevant non-dependent function types: f : .A → B This type implies that f does not depend computationally on its argument. One intended use case is data structures with embedded proofs, like sorted lists: postulate _≤_ : ℕ → ℕ → Set p₁ : 0 ≤ 1 p₂ : 0 ≤ 1 data SList (bound : ℕ) : Set where [] : SList bound scons : (head : ℕ) → .(head ≤ bound) → (tail : SList head) → SList bound The effect of the irrelevant type in the signature of scons is that scons's second argument is never inspected after Agda has ensured that it has the right type. It is even thrown away, leading to smaller term sizes and hopefully some gain in efficiency. The type-checker ignores irrelevant arguments when checking equality, so two lists can be equal even if they contain different proofs: l₁ : SList 1 l₁ = scons 0 p₁ [] l₂ : SList 1 l₂ = scons 0 p₂ [] l₁≡l₂ : l₁ ≡ l₂ l₁≡l₂ = refl Irrelevant arguments can only be used in irrelevant contexts. Consider the following subset type: data Subset (A : Set) (P : A → Set) : Set where _#_ : (elem : A) → .(P elem) → Subset A P The following two uses are fine: elimSubset : ∀ {A C : Set} {P} → Subset A P → ((a : A) → .(P a) → C) → C elimSubset (a # p) k = k a p elem : {A : Set} {P : A → Set} → Subset A P → A elem (x # p) = x However, if we try to project out the proof component, then Agda complains that "variable p is declared irrelevant, so it cannot be used here": prjProof : ∀ {A P} (x : Subset A P) → P (elem x) prjProof (a # p) = p Matching against irrelevant arguments is also forbidden, except in the case of irrefutable matches (record constructor patterns which have been translated away). For instance, the match against the pattern (p , q) here is accepted: elim₂ : ∀ {A C : Set} {P Q : A → Set} → Subset A (λ x → Σ (P x) (λ _ → Q x)) → ((a : A) → .(P a) → .(Q a) → C) → C elim₂ (a # (p , q)) k = k a p q Absurd matches () are also allowed. Note that record fields can also be irrelevant. Example: record Subset (A : Set) (P : A → Set) : Set where constructor _#_ field elem : A .proof : P elem Irrelevant fields are never in scope, neither inside nor outside the record. This means that no record field can depend on an irrelevant field, and furthermore projections are not defined for such fields. Irrelevant fields can only be accessed using pattern matching, as in elimSubset above. Irrelevant function types were added very recently, and have not been subjected to much experimentation yet, so do not be surprised if something is changed before the next release. For instance, dependent irrelevant function spaces (.(x : A) → B) might be added in the future. * Mixfix binders. It is now possible to declare user-defined syntax that binds identifiers. Example: postulate State : Set → Set → Set put : ∀ {S} → S → State S ⊤ get : ∀ {S} → State S S return : ∀ {A S} → A → State S A bind : ∀ {A B S} → State S B → (B → State S A) → State S A syntax bind e₁ (λ x → e₂) = x ← e₁ , e₂ increment : State ℕ ⊤ increment = x ← get , put (1 + x) The syntax declaration for bind implies that x is in scope in e₂, but not in e₁. You can give fixity declarations along with syntax declarations: infixr 40 bind syntax bind e₁ (λ x → e₂) = x ← e₁ , e₂ The fixity applies to the syntax, not the name; syntax declarations are also restricted to ordinary, non-operator names. The following declaration is disallowed: syntax _==_ x y = x === y Syntax declarations must also be linear; the following declaration is disallowed: syntax wrong x = x + x Syntax declarations were added very recently, and have not been subjected to much experimentation yet, so do not be surprised if something is changed before the next release. * Prop has been removed from the language. The experimental sort Prop has been disabled. Any program using Prop should typecheck if Prop is replaced by Set₀. Note that Prop is still a keyword. * Injective type constructors off by default. Automatic injectivity of type constructors has been disabled (by default). To enable it, use the flag --injective-type-constructors, either on the command line or in an OPTIONS pragma. Note that this flag makes Agda anti-classical and possibly inconsistent: Agda with excluded middle is inconsistent http://thread.gmane.org/gmane.comp.lang.agda/1367 See test/succeed/InjectiveTypeConstructors.agda for an example. * Termination checker can count. There is a new flag --termination-depth=N accepting values N >= 1 (with N = 1 being the default) which influences the behavior of the termination checker. So far, the termination checker has only distinguished three cases when comparing the argument of a recursive call with the formal parameter of the callee. < : the argument is structurally smaller than the parameter = : they are equal ? : the argument is bigger or unrelated to the parameter This behavior, which is still the default (N = 1), will not recognise the following functions as terminating. mutual f : ℕ → ℕ f zero = zero f (suc zero) = zero f (suc (suc n)) = aux n aux : ℕ → ℕ aux m = f (suc m) The call graph f --(<)--> aux --(?)--> f yields a recursive call from f to f via aux where the relation of call argument to callee parameter is computed as "unrelated" (composition of < and ?). Setting N >= 2 allows a finer analysis: n has two constructors less than suc (suc n), and suc m has one more than m, so we get the call graph: f --(-2)--> aux --(+1)--> f The indirect call f --> f is now labeled with (-1), and the termination checker can recognise that the call argument is decreasing on this path. Setting the termination depth to N means that the termination checker counts decrease up to N and increase up to N-1. The default, N=1, means that no increase is counted, every increase turns to "unrelated". In practice, examples like the one above sometimes arise when "with" is used. As an example, the program f : ℕ → ℕ f zero = zero f (suc zero) = zero f (suc (suc n)) with zero ... | _ = f (suc n) is internally represented as mutual f : ℕ → ℕ f zero = zero f (suc zero) = zero f (suc (suc n)) = aux n zero aux : ℕ → ℕ → ℕ aux m k = f (suc m) Thus, by default, the definition of f using "with" is not accepted by the termination checker, even though it looks structural (suc n is a subterm of suc suc n). Now, the termination checker is satisfied if the option "--termination-depth=2" is used. Caveats: - This is an experimental feature, hopefully being replaced by something smarter in the near future. - Increasing the termination depth will quickly lead to very long termination checking times. So, use with care. Setting termination depth to 100 by habit, just to be on the safe side, is not a good idea! - Increasing termination depth only makes sense for linear data types such as ℕ and Size. For other types, increase cannot be recognised. For instance, consider a similar example with lists. data List : Set where nil : List cons : ℕ → List → List mutual f : List → List f nil = nil f (cons x nil) = nil f (cons x (cons y ys)) = aux y ys aux : ℕ → List → List aux z zs = f (cons z zs) Here the termination checker compares cons z zs to z and also to zs. In both cases, the result will be "unrelated", no matter how high we set the termination depth. This is because when comparing cons z zs to zs, for instance, z is unrelated to zs, thus, cons z zs is also unrelated to zs. We cannot say it is just "one larger" since z could be a very large term. Note that this points to a weakness of untyped termination checking. To regain the benefit of increased termination depth, we need to index our lists by a linear type such as ℕ or Size. With termination depth 2, the above example is accepted for vectors instead of lists. * The codata keyword has been removed. To use coinduction, use the following new builtins: INFINITY, SHARP and FLAT. Example: {-# OPTIONS --universe-polymorphism #-} module Coinduction where open import Level infix 1000 ♯_ postulate ∞ : ∀ {a} (A : Set a) → Set a ♯_ : ∀ {a} {A : Set a} → A → ∞ A ♭ : ∀ {a} {A : Set a} → ∞ A → A {-# BUILTIN INFINITY ∞ #-} {-# BUILTIN SHARP ♯_ #-} {-# BUILTIN FLAT ♭ #-} Note that (non-dependent) pattern matching on SHARP is no longer allowed. Note also that strange things might happen if you try to combine the pragmas above with COMPILED_TYPE, COMPILED_DATA or COMPILED pragmas, or if the pragmas do not occur right after the postulates. The compiler compiles the INFINITY builtin to nothing (more or less), so that the use of coinduction does not get in the way of FFI declarations: data Colist (A : Set) : Set where [] : Colist A _∷_ : (x : A) (xs : ∞ (Colist A)) → Colist A {-# COMPILED_DATA Colist [] [] (:) #-} * Infinite types. If the new flag --guardedness-preserving-type-constructors is used, then type constructors are treated as inductive constructors when we check productivity (but only in parameters, and only if they are used strictly positively or not at all). This makes examples such as the following possible: data Rec (A : ∞ Set) : Set where fold : ♭ A → Rec A -- Σ cannot be a record type below. data Σ (A : Set) (B : A → Set) : Set where _,_ : (x : A) → B x → Σ A B syntax Σ A (λ x → B) = Σ[ x ∶ A ] B -- Corecursive definition of the W-type. W : (A : Set) → (A → Set) → Set W A B = Rec (♯ (Σ[ x ∶ A ] (B x → W A B))) syntax W A (λ x → B) = W[ x ∶ A ] B sup : {A : Set} {B : A → Set} (x : A) (f : B x → W A B) → W A B sup x f = fold (x , f) W-rec : {A : Set} {B : A → Set} (P : W A B → Set) → (∀ {x} {f : B x → W A B} → (∀ y → P (f y)) → P (sup x f)) → ∀ x → P x W-rec P h (fold (x , f)) = h (λ y → W-rec P h (f y)) -- Induction-recursion encoded as corecursion-recursion. data Label : Set where ′0 ′1 ′2 ′σ ′π ′w : Label mutual U : Set U = Σ Label U′ U′ : Label → Set U′ ′0 = ⊤ U′ ′1 = ⊤ U′ ′2 = ⊤ U′ ′σ = Rec (♯ (Σ[ a ∶ U ] (El a → U))) U′ ′π = Rec (♯ (Σ[ a ∶ U ] (El a → U))) U′ ′w = Rec (♯ (Σ[ a ∶ U ] (El a → U))) El : U → Set El (′0 , _) = ⊥ El (′1 , _) = ⊤ El (′2 , _) = Bool El (′σ , fold (a , b)) = Σ[ x ∶ El a ] El (b x) El (′π , fold (a , b)) = (x : El a) → El (b x) El (′w , fold (a , b)) = W[ x ∶ El a ] El (b x) U-rec : (P : ∀ u → El u → Set) → P (′1 , _) tt → P (′2 , _) true → P (′2 , _) false → (∀ {a b x y} → P a x → P (b x) y → P (′σ , fold (a , b)) (x , y)) → (∀ {a b f} → (∀ x → P (b x) (f x)) → P (′π , fold (a , b)) f) → (∀ {a b x f} → (∀ y → P (′w , fold (a , b)) (f y)) → P (′w , fold (a , b)) (sup x f)) → ∀ u (x : El u) → P u x U-rec P P1 P2t P2f Pσ Pπ Pw = rec where rec : ∀ u (x : El u) → P u x rec (′0 , _) () rec (′1 , _) _ = P1 rec (′2 , _) true = P2t rec (′2 , _) false = P2f rec (′σ , fold (a , b)) (x , y) = Pσ (rec _ x) (rec _ y) rec (′π , fold (a , b)) f = Pπ (λ x → rec _ (f x)) rec (′w , fold (a , b)) (fold (x , f)) = Pw (λ y → rec _ (f y)) The --guardedness-preserving-type-constructors extension is based on a rather operational understanding of ∞/♯_; it's not yet clear if this extension is consistent. * Qualified constructors. Constructors can now be referred to qualified by their data type. For instance, given data Nat : Set where zero : Nat suc : Nat → Nat data Fin : Nat → Set where zero : ∀ {n} → Fin (suc n) suc : ∀ {n} → Fin n → Fin (suc n) you can refer to the constructors unambiguously as Nat.zero, Nat.suc, Fin.zero, and Fin.suc (Nat and Fin are modules containing the respective constructors). Example: inj : (n m : Nat) → Nat.suc n ≡ suc m → n ≡ m inj .m m refl = refl Previously you had to write something like inj : (n m : Nat) → _≡_ {Nat} (suc n) (suc m) → n ≡ m to make the type checker able to figure out that you wanted the natural number suc in this case. * Reflection. There are two new constructs for reflection: - quoteGoal x in e In e the value of x will be a representation of the goal type (the type expected of the whole expression) as an element in a datatype of Agda terms (see below). For instance, example : ℕ example = quoteGoal x in {! at this point x = def (quote ℕ) [] !} - quote x : Name If x is the name of a definition (function, datatype, record, or a constructor), quote x gives you the representation of x as a value in the primitive type Name (see below). Quoted terms use the following BUILTINs and primitives (available from the standard library module Reflection): -- The type of Agda names. postulate Name : Set {-# BUILTIN QNAME Name #-} primitive primQNameEquality : Name → Name → Bool -- Arguments. Explicit? = Bool data Arg A : Set where arg : Explicit? → A → Arg A {-# BUILTIN ARG Arg #-} {-# BUILTIN ARGARG arg #-} -- The type of Agda terms. data Term : Set where var : ℕ → List (Arg Term) → Term con : Name → List (Arg Term) → Term def : Name → List (Arg Term) → Term lam : Explicit? → Term → Term pi : Arg Term → Term → Term sort : Term unknown : Term {-# BUILTIN AGDATERM Term #-} {-# BUILTIN AGDATERMVAR var #-} {-# BUILTIN AGDATERMCON con #-} {-# BUILTIN AGDATERMDEF def #-} {-# BUILTIN AGDATERMLAM lam #-} {-# BUILTIN AGDATERMPI pi #-} {-# BUILTIN AGDATERMSORT sort #-} {-# BUILTIN AGDATERMUNSUPPORTED unknown #-} Reflection may be useful when working with internal decision procedures, such as the standard library's ring solver. * Minor record definition improvement. The definition of a record type is now available when type checking record module definitions. This means that you can define things like the following: record Cat : Set₁ where field Obj : Set _=>_ : Obj → Obj → Set -- ... -- not possible before: op : Cat op = record { Obj = Obj; _=>_ = λ A B → B => A } Tools ----- * The "Goal type and context" command now shows the goal type before the context, and the context is shown in reverse order. The "Goal type, context and inferred type" command has been modified in a similar way. * Show module contents command. Given a module name M the Emacs mode can now display all the top-level modules and names inside M, along with types for the names. The command is activated using C-c C-o or the menus. * Auto command. A command which searches for type inhabitants has been added. The command is invoked by pressing C-C C-a (or using the goal menu). There are several flags and parameters, e.g. '-c' which enables case-splitting in the search. For further information, see the Agda wiki: http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Main.Auto * HTML generation is now possible for a module with unsolved meta-variables, provided that the --allow-unsolved-metas flag is used. Agda-2.3.2.2/doc/release-notes/2-3-2.txt0000644000000000000000000004760612221362553015432 0ustar0000000000000000------------------------------------------------------------------------ -- Release notes for Agda 2 version 2.3.2 ------------------------------------------------------------------------ Important changes since 2.3.0: Installation ============ * The Agda-executable package has been removed. The executable is now provided as part of the Agda package. * The Emacs mode no longer depends on haskell-mode or GHCi. * Compilation of Emacs mode Lisp files. You can now compile the Emacs mode Lisp files by running "agda-mode compile". This command is run by "make install". Compilation can, in some cases, give a noticeable speedup. WARNING: If you reinstall the Agda mode without recompiling the Emacs Lisp files, then Emacs may continue using the old, compiled files. Pragmas and Options =================== * The --without-K check now reconstructs constructor parameters. New specification of --without-K: If the flag is activated, then Agda only accepts certain case-splits. If the type of the variable to be split is D pars ixs, where D is a data (or record) type, pars stands for the parameters, and ixs the indices, then the following requirements must be satisfied: * The indices ixs must be applications of constructors (or literals) to distinct variables. Constructors are usually not applied to parameters, but for the purposes of this check constructor parameters are treated as other arguments. * These distinct variables must not be free in pars. * Irrelevant arguments are printed as _ by default now. To turn on printing of irrelevant arguments, use option --show-irrelevant * New: Pragma NO_TERMINATION_CHECK to switch off termination checker for individual function definitions and mutual blocks. The pragma must precede a function definition or a mutual block. Examples (see test/succeed/NoTerminationCheck.agda): 1. Skipping a single definition: before type signature. {-# NO_TERMINATION_CHECK #-} a : A a = a 2. Skipping a single definition: before first clause. b : A {-# NO_TERMINATION_CHECK #-} b = b 3. Skipping an old-style mutual block: Before 'mutual' keyword. {-# NO_TERMINATION_CHECK #-} mutual c : A c = d d : A d = c 4. Skipping a new-style mutual block: Anywhere before a type signature or first function clause in the block i : A j : A i = j {-# NO_TERMINATION_CHECK #-} j = i The pragma cannot be used in --safe mode. Language ======== * Let binding record patterns record _×_ (A B : Set) : Set where constructor _,_ field fst : A snd : B open _×_ let (x , (y , z)) = t in u will now be interpreted as let x = fst t y = fst (snd t) z = snd (snd t) in u Note that the type of t needs to be inferable. If you need to provide a type signature, you can write the following: let a : ... a = t (x , (y , z)) = a in u * Pattern synonyms A pattern synonym is a declaration that can be used on the left hand side (when pattern matching) as well as the right hand side (in expressions). For example: pattern z = zero pattern ss x = suc (suc x) f : ℕ -> ℕ f z = z f (suc z) = ss z f (ss n) = n Pattern synonyms are implemented by substitution on the abstract syntax, so definitions are scope-checked but not type-checked. They are particularly useful for universe constructions. * Qualified mixfix operators It is now possible to use a qualified mixfix operator by qualifying the first part of the name. For instance import Data.Nat as Nat import Data.Bool as Bool two = Bool.if true then 1 Nat.+ 1 else 0 * Sections [Issue 735]. Agda now parses anonymous modules as sections: module _ {a} (A : Set a) where data List : Set a where [] : List _∷_ : (x : A) (xs : List) → List module _ {a} {A : Set a} where _++_ : List A → List A → List A [] ++ ys = ys (x ∷ xs) ++ ys = x ∷ (xs ++ ys) test : List Nat test = (5 ∷ []) ++ (3 ∷ []) In general, now the syntax module _ parameters where declarations is accepted and has the same effect as private module M parameters where declarations open M public for a fresh name M. * Instantiating a module in an open import statement [Issue 481]. Now accepted: open import Path.Module args [using/hiding/renaming (...)] This only brings the imported identifiers from Path.Module into scope, not the module itself! Consequently, the following is pointless, and raises an error: import Path.Module args [using/hiding/renaming (...)] You can give a private name M to the instantiated module via import Path.Module args as M [using/hiding/renaming (...)] open import Path.Module args as M [using/hiding/renaming (...)] Try to avoid 'as' as part of the arguments. 'as' is not a keyword; the following can be legal, although slightly obfuscated Agda code: open import as as as as as as * Implicit module parameters can be given by name. E.g. open M {namedArg = bla} This feature has been introduced in Agda 2.3.0 already. * Multiple type signatures sharing a same type can now be written as a single type signature. one two : ℕ one = suc zero two = suc one Goal and error display ====================== * Meta-variables that were introduced by hidden argument `arg' are now printed as _arg_number instead of just _number. [Issue 526] * Agda expands identifiers in anonymous modules when printing. Should make some goals nicer to read. [Issue 721] * When a module identifier is ambiguous, Agda tells you if one of them is a data type module. [Issues 318, 705] Type checking ============= * Improved coverage checker. The coverage checker splits on arguments that have constructor or literal pattern, committing to the left-most split that makes progress. Consider the lookup function for vectors: data Fin : Nat → Set where zero : {n : Nat} → Fin (suc n) suc : {n : Nat} → Fin n → Fin (suc n) data Vec (A : Set) : Nat → Set where [] : Vec A zero _∷_ : {n : Nat} → A → Vec A n → Vec A (suc n) _!!_ : {A : Set}{n : Nat} → Vec A n → Fin n → A (x ∷ xs) !! zero = x (x ∷ xs) !! suc i = xs !! i In Agda up to 2.3.0, this definition is rejected unless we add an absurd clause [] !! () This is because the coverage checker committed on splitting on the vector argument, even though this inevitably lead to failed coverage, because a case for the empty vector [] is missing. The improvement to the coverage checker consists on committing only on splits that have a chance of covering, since all possible constructor patterns are present. Thus, Agda will now split first on the Fin argument, since cases for both zero and suc are present. Then, it can split on the Vec argument, since the empty vector is already ruled out by instantiating n to a suc _. * Instance arguments resolution will now consider candidates which still expect hidden arguments. For example: record Eq (A : Set) : Set where field eq : A → A → Bool open Eq {{...}} eqFin : {n : ℕ} → Eq (Fin n) eqFin = record { eq = primEqFin } testFin : Bool testFin = eq fin1 fin2 The type-checker will now resolve the instance argument of the eq function to eqFin {_}. This is only done for hidden arguments, not instance arguments, so that the instance search stays non-recursive. * Constraint solving: Upgraded Miller patterns to record patterns. [Issue 456] Agda now solves meta-variables that are applied to record patterns. A typical (but here, artificial) case is: record Sigma (A : Set)(B : A -> Set) : Set where constructor _,_ field fst : A snd : B fst test : (A : Set)(B : A -> Set) -> let X : Sigma A B -> Sigma A B X = _ in (x : A)(y : B x) -> X (x , y) ≡ (x , y) test A B x y = refl This yields a constraint of the form _X A B (x , y) := t[x,y] (with t[x,y] = (x, y)) which is not a Miller pattern. However, Agda now solves this as _X A B z := t[fst z,snd z]. * Changed: solving recursive constraints. [Issue 585] Until 2.3.0, Agda sometimes inferred values that did not pass the termination checker later, or would even make Agda loop. To prevent this, the occurs check now also looks into the definitions of the current mutual block, to avoid constructing recursive solutions. As a consequence, also terminating recursive solutions are no longer found automatically. This effects a programming pattern where the recursively computed type of a recursive function is left to Agda to solve. mutual T : D -> Set T pattern1 = _ T pattern2 = _ f : (d : D) -> T d f pattern1 = rhs1 f pattern2 = rhs2 This might no longer work from now on. See examples test/fail/Issue585*.agda * Less eager introduction of implicit parameters. [Issue 679] Until Agda 2.3.0, trailing hidden parameters were introduced eagerly on the left hand side of a definition. For instance, one could not write test : {A : Set} -> Set test = \ {A} -> A because internally, the hidden argument {A : Set} was added to the left-hand side, yielding test {_} = \ {A} -> A which raised a type error. Now, Agda only introduces the trailing implicit parameters it has to, in order to maintain uniform function arity. For instance, in test : Bool -> {A B C : Set} -> Set test true {A} = A test false {B = B} = B Agda will introduce parameters A and B in all clauses, but not C, resulting in test : Bool -> {A B C : Set} -> Set test true {A} {_} = A test false {_} {B = B} = B Note that for checking where-clauses, still all hidden trailing parameters are in scope. For instance: id : {i : Level}{A : Set i} -> A -> A id = myId where myId : forall {A} -> A -> A myId x = x To be able to fill in the meta variable _1 in myId : {A : Set _1} -> A -> A the hidden parameter {i : Level} needs to be in scope. As a result of this more lazy introduction of implicit parameters, the following code now passes. data Unit : Set where unit : Unit T : Unit → Set T unit = {u : Unit} → Unit test : (u : Unit) → T u test unit with unit ... | _ = λ {v} → v Before, Agda would eagerly introduce the hidden parameter {v} as unnamed left-hand side parameter, leaving no way to refer to it. The related issue 655 has also been addressed. It is now possible to make `synonym' definitions name = expression even when the type of expression begins with a hidden quantifier. Simple example: id2 = id That resulted in unsolved metas until 2.3.0. * Agda detects unused arguments and ignores them during equality checking. [Issue 691, solves also issue 44.] Agda's polarity checker now assigns 'Nonvariant' to arguments that are not actually used (except for absurd matches). If f's first argument is Nonvariant, then f x is definitionally equal to f y regardless of x and y. It is similar to irrelevance, but does not require user annotation. For instance, unused module parameters do no longer get in the way: module M (x : Bool) where not : Bool → Bool not true = false not false = true open M true open M false renaming (not to not′) test : (y : Bool) → not y ≡ not′ y test y = refl Matching against record or absurd patterns does not count as `use', so we get some form of proof irrelevance: data ⊥ : Set where record ⊤ : Set where constructor trivial data Bool : Set where true false : Bool True : Bool → Set True true = ⊤ True false = ⊥ fun : (b : Bool) → True b → Bool fun true trivial = true fun false () test : (b : Bool) → (x y : True b) → fun b x ≡ fun b y test b x y = refl More examples in test/succeed/NonvariantPolarity.agda. Phantom arguments: Parameters of record and data types are considered `used' even if they are not actually used. Consider: False : Nat → Set False zero = ⊥ False (suc n) = False n module Invariant where record Bla (n : Nat)(p : False n) : Set where module Nonvariant where Bla : (n : Nat) → False n → Set Bla n p = ⊤ Even though record `Bla' does not use its parameters n and p, they are considered as used, allowing "phantom type" techniques. In contrast, the arguments of function `Bla' are recognized as unused. The following code type-checks if we open Invariant but leaves unsolved metas if we open Nonvariant. drop-suc : {n : Nat}{p : False n} → Bla (suc n) p → Bla n p drop-suc _ = _ bla : (n : Nat) → {p : False n} → Bla n p → ⊥ bla zero {()} b bla (suc n) b = bla n (drop-suc b) If `Bla' is considered invariant, the hidden argument in the recursive call can be inferred to be `p'. If it is considered non-variant, then `Bla n X = Bla n p' does not entail `X = p' and the hidden argument remains unsolved. Since `bla' does not actually use its hidden argument, its value is not important and it could be searched for. Unfortunately, polarity analysis of `bla' happens only after type checking, thus, the information that `bla' is non-variant in `p' is not available yet when meta-variables are solved. (See test/fail/BrokenInferenceDueToNonvariantPolarity.agda) * Agda now expands simple definitions (one clause, terminating) to check whether a function is constructor headed. [Issue 747] For instance, the following now also works: MyPair : Set -> Set -> Set MyPair A B = Pair A B Vec : Set -> Nat -> Set Vec A zero = Unit Vec A (suc n) = MyPair A (Vec A n) Here, Unit and Pair are data or record types. Compiler backends ================= * -Werror is now overridable. To enable compilation of Haskell modules containing warnings, the -Werror flag for the MAlonzo backend has been made overridable. If, for example, --ghc-flag=-Wwarn is passed when compiling, one can get away with things like: data PartialBool : Set where true : PartialBool {-# COMPILED_DATA PartialBool Bool True #-} The default behavior remains as it used to be and rejects the above program. Tools ===== Emacs mode ---------- * Asynchronous Emacs mode. One can now use Emacs while a buffer is type-checked. If the buffer is edited while the type-checker runs, then syntax highlighting will not be updated when type-checking is complete. * Interactive syntax highlighting. The syntax highlighting is updated while a buffer is type-checked: • At first the buffer is highlighted in a somewhat crude way (without go-to-definition information for overloaded constructors). • If the highlighting level is "interactive", then the piece of code that is currently being type-checked is highlighted as such. (The default is "non-interactive".) • When a mutual block has been type-checked it is highlighted properly (this highlighting includes warnings for potential non-termination). The highlighting level can be controlled via the new configuration variable agda2-highlight-level. * Multiple case-splits can now be performed in one go. Consider the following example: _==_ : Bool → Bool → Bool b₁ == b₂ = {!!} If you split on "b₁ b₂", then you get the following code: _==_ : Bool → Bool → Bool true == true = {!!} true == false = {!!} false == true = {!!} false == false = {!!} The order of the variables matters. Consider the following code: lookup : ∀ {a n} {A : Set a} → Vec A n → Fin n → A lookup xs i = {!!} If you split on "xs i", then you get the following code: lookup : ∀ {a n} {A : Set a} → Vec A n → Fin n → A lookup [] () lookup (x ∷ xs) zero = {!!} lookup (x ∷ xs) (suc i) = {!!} However, if you split on "i xs", then you get the following code instead: lookup : ∀ {a n} {A : Set a} → Vec A n → Fin n → A lookup (x ∷ xs) zero = ? lookup (x ∷ xs) (suc i) = ? This code is rejected by Agda 2.3.0, but accepted by 2.3.2 thanks to improved coverage checking (see above). * The Emacs mode now presents information about which module is currently being type-checked. * New global menu entry: Information about the character at point. If this entry is selected, then information about the character at point is displayed, including (in many cases) information about how to type the character. * Commenting/uncommenting the rest of the buffer. One can now comment or uncomment the rest of the buffer by typing C-c C-x M-; or by selecting the menu entry "Comment/uncomment the rest of the buffer". * The Emacs mode now uses the Agda executable instead of GHCi. The *ghci* buffer has been renamed to *agda2*. A new configuration variable has been introduced: agda2-program-name, the name of the Agda executable (by default agda). The variable agda2-ghci-options has been replaced by agda2-program-args: extra arguments given to the Agda executable (by default none). If you want to limit Agda's memory consumption you can add some arguments to agda2-program-args, for instance +RTS -M1.5G -RTS. * The Emacs mode no longer depends on haskell-mode. Users who have customised certain haskell-mode variables (such as haskell-ghci-program-args) may want to update their configuration. LaTeX-backend ------------- An experimental LaTeX-backend which does precise highlighting a la the HTML-backend and code alignment a la lhs2TeX has been added. Here is a sample input literate Agda file: \documentclass{article} \usepackage{agda} \begin{document} The following module declaration will be hidden in the output. \AgdaHide{ \begin{code} module M where \end{code} } Two or more spaces can be used to make the backend align stuff. \begin{code} data ℕ : Set where zero : ℕ suc : ℕ → ℕ _+_ : ℕ → ℕ → ℕ zero + n = n suc m + n = suc (m + n) \end{code} \end{document} To produce an output PDF issue the following commands: agda --latex -i . .lagda pdflatex latex/.tex Only the top-most module is processed, like with lhs2tex and unlike with the HTML-backend. If you want to process imported modules you have to call agda --latex manually on each of those modules. There are still issues related to formatting, see the bug tracker for more information: https://code.google.com/p/agda/issues/detail?id=697 The default agda.sty might therefore change in backwards-incompatible ways, as work proceeds in trying to resolve those problems. Implemented features: * Two or more spaces can be used to force alignment of things, like with lhs2tex. See example above. * The highlighting information produced by the type checker is used to generate the output. For example, the data declaration in the example above, produces: \AgdaKeyword{data} \AgdaDatatype{ℕ} \AgdaSymbol{:} \AgdaPrimitiveType{Set} \AgdaKeyword{where} These latex commands are defined in agda.sty (which is imported by \usepackage{agda}) and cause the highlighting. * The latex-backend checks if agda.sty is found by the latex environment, if it isn't a default agda.sty is copied from Agda's data-dir into the working directory (and thus made available to the latex environment). If the default agda.sty isn't satisfactory (colors, fonts, spacing, etc) then the user can modify it and make put it somewhere where the latex environment can find it. Hopefully most aspects should be modifiable via agda.sty rather than having to tweak the implementation. * --latex-dir can be used to change the default output directory. Agda-2.3.2.2/doc/release-notes/2-2-2.txt0000644000000000000000000000131212221362553015411 0ustar0000000000000000------------------------------------------------------------------------ -- Release notes for Agda 2 version 2.2.2 ------------------------------------------------------------------------ Important changes since 2.2.0: Tools ----- * The --malonzodir option has been renamed to --malonzo-dir. * The output of agda --html is by default placed in a directory called "html". Infrastructure -------------- * The Emacs mode is included in the Agda Cabal package, and installed by cabal install. The recommended way to enable the Emacs mode is to include the following code in .emacs: (load-file (let ((coding-system-for-read 'utf-8)) (shell-command-to-string "agda-mode locate"))) Agda-2.3.2.2/doc/release-notes/2-3-2-1.txt0000644000000000000000000000070312221362553015553 0ustar0000000000000000------------------------------------------------------------------------ -- Release notes for Agda 2 version 2.3.2.1 ------------------------------------------------------------------------ Important changes since 2.3.2: Installation ============ * Made it possible to compile Agda with more recent versions of hashable, QuickCheck and Win32. * Excluded mtl-2.1. Type checking ============= * Fixed bug in the termination checker (issue 754). Agda-2.3.2.2/doc/HCAR/0000755000000000000000000000000012221362553012163 5ustar0000000000000000Agda-2.3.2.2/doc/HCAR/November-2010.tex0000644000000000000000000000240212221362553015040 0ustar0000000000000000\documentclass{article} \usepackage{hcar} \begin{document} \begin{hcarentry}[section,updated]{Agda} \label{agda} \report{Nils Anders Danielsson}%11/10 \status{actively developed} \participants{Ulf Norell, Andreas Abel, and many others} \makeheader Agda is a dependently typed functional programming language (developed using Haskell). A central feature of Agda is inductive families, i.e.\ GADTs which can be indexed by \emph{values} and not just types. The language also supports coinductive types, parameterized modules, and mixfix operators, and comes with an \emph{interactive} interface---the type checker can assist you in the development of your code. A lot of work remains in order for Agda to become a full-fledged programming language (good libraries, mature compilers, documentation, etc.), but already in its current state it can provide lots of fun as a platform for experiments in dependently typed programming. In September version 2.2.8 was released, with these new features: \begin{itemize} \item Pattern matching for records. \item Proof-irrelevant function types. \item Reflection. \item Users can define new forms of binding syntax. \end{itemize} \FurtherReading The Agda Wiki: \url{http://wiki.portal.chalmers.se/agda/} \end{hcarentry} \end{document} Agda-2.3.2.2/doc/HCAR/May-2008.tex0000644000000000000000000000244112221362553014023 0ustar0000000000000000\documentclass{article} \usepackage{hcar} \begin{document} \begin{hcarentry}{Agda} \label{agda} \report{Nils Anders Danielsson} \status{Actively developed by a number of people} \makeheader Do you crave for highly expressive types, but do not want to resort to type-class hackery? Then Agda might provide a view of what the future has in store for you. Agda is a dependently typed functional programming language (developed using Haskell). The language has inductive families, i.e.\ GADTs which can be indexed by \emph{values} and not just types. Other goodies include parameterised modules, mixfix operators, and an \emph{interactive} Emacs interface (the type checker can assist you in the development of your code). A lot of work remains in order for Agda to become a full-fledged programming language (effects, good libraries, mature compilers, documentation, etc.), but already in its current state it can provide lots of fun as a platform for experiments in dependently typed programming. New since last time: \begin{itemize} \item A simple foreign function interface, which allows use of Haskell functions in Agda code. \item The libraries are steadily increasing in size. \end{itemize} \FurtherReading The Agda Wiki: \url{http://www.cs.chalmers.se/~ulfn/Agda/} \end{hcarentry} \end{document} Agda-2.3.2.2/doc/HCAR/November-2011.tex0000644000000000000000000000267512221362553015055 0ustar0000000000000000\documentclass{article} \usepackage{hcar} \begin{document} \begin{hcarentry}[section,updated]{Agda} \label{agda} \report{Nils Anders Danielsson}%11/11 \status{actively developed} \participants{Ulf Norell, Andreas Abel, and many others} \makeheader Agda is a dependently typed functional programming language (developed using Haskell). A central feature of Agda is inductive families, i.e.\ GADTs which can be indexed by \emph{values} and not just types. The language also supports coinductive types, parameterized modules, and mixfix operators, and comes with an \emph{interactive} interface---the type checker can assist you in the development of your code. A lot of work remains in order for Agda to become a full-fledged programming language (good libraries, mature compilers, documentation, etc.), but already in its current state it can provide lots of fun as a platform for experiments in dependently typed programming. At the time of writing version 2.3.0 is about to be released, with the following new features (among others): \begin{itemize} \item Instance arguments (Dominique Devriese). \item A JavaScript backend (Alan Jeffrey). \item More optimizations in the Epic backend (Olle Fredriksson and Daniel Gustafsson). \item Pattern matching, multi-clause lambdas (Fredrik Nordvall Forsberg, Karim Kanso and Noam Zeilberger). \end{itemize} \FurtherReading The Agda Wiki: \url{http://wiki.portal.chalmers.se/agda/} \end{hcarentry} \end{document} Agda-2.3.2.2/doc/HCAR/May-2009.tex0000644000000000000000000000315012221362553014022 0ustar0000000000000000\documentclass{article} \usepackage{hcar} \begin{document} \begin{hcarentry}[updated]{Agda} \label{agda} \report{Nils Anders Danielsson}%05/09 \status{actively developed} \participants{Ulf Norell and many others} \makeheader Do you crave for highly expressive types, but do not want to resort to type-class hackery? Then Agda might provide a view of what the future has in store for you. Agda is a dependently typed functional programming language (developed using Haskell). The language has inductive families, i.e.\ GADTs which can be indexed by \emph{values} and not just types. Other goodies include coinductive types, parameterized modules, mixfix operators, and an \emph{interactive} Emacs interface (the type checker can assist you in the development of your code). A lot of work remains in order for Agda to become a full-fledged programming language (good libraries, mature compilers, documentation, etc.), but already in its current state it can provide lots of fun as a platform for experiments in dependently typed programming. New since last time: \begin{itemize} \item Versions 2.2.0 and 2.2.2 have been released. The previous release was in 2007, so the new versions include lots of changes. \item Agda is now available on Hackage (\texttt{cabal install Agda-executable}). \item Highlighted, hyperlinked HTML can be generated from Agda source code using \texttt{agda --html}. \item The Agda Wiki is better organized, so it should be easier for a newcomer to find relevant information. \end{itemize} \FurtherReading The Agda Wiki: \url{http://wiki.portal.chalmers.se/agda/} \end{hcarentry} \end{document} Agda-2.3.2.2/doc/HCAR/November-2008.tex0000644000000000000000000000366012221362553015056 0ustar0000000000000000\documentclass{article} \usepackage{hcar} \begin{document} \begin{hcarentry}[updated]{Agda} \label{agda} \report{Nils Anders Danielsson} \status{Actively developed} \participants{Ulf Norell and many others} \makeheader Do you crave for highly expressive types, but do not want to resort to type-class hackery? Then Agda might provide a view of what the future has in store for you. Agda is a dependently typed functional programming language (developed using Haskell). The language has inductive families, i.e.\ GADTs which can be indexed by \emph{values} and not just types. Other goodies include parameterised modules, mixfix operators, and an \emph{interactive} Emacs interface (the type checker can assist you in the development of your code). A lot of work remains in order for Agda to become a full-fledged programming language (good libraries, mature compilers, documentation, etc.), but already in its current state it can provide lots of fun as a platform for experiments in dependently typed programming. New since last time: \begin{itemize} \item Coinductive types (types with possibly infinite values). \item Case-split: The user interface can replace a pattern variable with the corresponding constructor patterns. You get one new left-hand side for every possible constructor. \item The foreign function interface now ensures that the foreign (Haskell) code has types matching the Agda code. \item Sized types, which can make it easier to explain why your code is terminating, are currently being implemented by Ulf Norell and Andreas Abel. \item Agda packages for Debian/Ubuntu have been prepared by Liyang HU, and Kuragaki-san has constructed a new Agda installer for Windows. \item A new Emacs input method, which contains bindings for many Unicode symbols, has been implemented by Nils Anders Danielsson. \end{itemize} \FurtherReading The Agda Wiki: \url{http://www.cs.chalmers.se/~ulfn/Agda/} \end{hcarentry} \end{document} Agda-2.3.2.2/doc/HCAR/December-2007.tex0000644000000000000000000000211512221362553015000 0ustar0000000000000000\documentclass{article} \usepackage{hcar} \begin{document} \begin{hcarentry}{Agda} \report{Nils Anders Danielsson} \status{Actively developed by a number of people} \makeheader Do you crave for highly expressive types, but do not want to resort to type-class hackery? Then Agda might provide a view of what the future has in store for you. Agda is a dependently typed functional programming language (developed using Haskell). The language has inductive families, i.e.\@ GADTs which can be indexed by \emph{values} and not just types. Other goodies include parameterised modules, mixfix operators, and an \emph{interactive} Emacs interface (the type checker can assist you in the development of your code). A lot of work remains in order for Agda to become a full-fledged programming language (effects, good libraries, mature compilers, documentation, \ldots), but already in its current state it can provide lots of fun as a platform for experiments in dependently typed programming. \FurtherReading The Agda Wiki: \url{http://www.cs.chalmers.se/~ulfn/Agda/} \end{hcarentry} \end{document} Agda-2.3.2.2/doc/HCAR/May-2011.tex0000644000000000000000000000246412221362553014022 0ustar0000000000000000\documentclass{article} \usepackage{hcar} \begin{document} \begin{hcarentry}[section,updated]{Agda} \label{agda} \report{Nils Anders Danielsson}%05/11 \status{actively developed} \participants{Ulf Norell, Andreas Abel, and many others} \makeheader Agda is a dependently typed functional programming language (developed using Haskell). A central feature of Agda is inductive families, i.e.\ GADTs which can be indexed by \emph{values} and not just types. The language also supports coinductive types, parameterized modules, and mixfix operators, and comes with an \emph{interactive} interface---the type checker can assist you in the development of your code. A lot of work remains in order for Agda to become a full-fledged programming language (good libraries, mature compilers, documentation, etc.), but already in its current state it can provide lots of fun as a platform for experiments in dependently typed programming. In February version 2.2.10 was released. This release includes a new compiler backend, implemented by Daniel Gustafsson and Olle Fredriksson. The backend incorporates several new optimisations, based on work by Edwin Brady and others, and work is in progress to add even more optimisations. \FurtherReading The Agda Wiki: \url{http://wiki.portal.chalmers.se/agda/} \end{hcarentry} \end{document} Agda-2.3.2.2/doc/HCAR/November-2012.tex0000644000000000000000000000246512221362553015053 0ustar0000000000000000\documentclass{article} \usepackage{hcar} \begin{document} % Agda-NA.tex \begin{hcarentry}[section,updated]{Agda} \label{agda} \report{Nils Anders Danielsson}%11/12 \status{actively developed} \participants{Ulf Norell, Andreas Abel, and many others} \makeheader Agda is a dependently typed functional programming language (developed using Haskell). A central feature of Agda is inductive families, i.e.\ GADTs which can be indexed by \emph{values} and not just types. The language also supports coinductive types, parameterized modules, and mixfix operators, and comes with an \emph{interactive} interface---the type checker can assist you in the development of your code. A lot of work remains in order for Agda to become a full-fledged programming language (good libraries, mature compilers, documentation, etc.), but already in its current state it can provide lots of fun as a platform for experiments in dependently typed programming. The next version of Agda is still under development. Some of the changes were mentioned in the last HCAR entry. More recently Stevan Andjelkovic has contributed a LaTeX backend, with the aim to support both precise, Agda-style highlighting, and lhs2TeX-style alignment of code. \FurtherReading The Agda Wiki: \url{http://wiki.portal.chalmers.se/agda/} \end{hcarentry} \end{document} Agda-2.3.2.2/doc/HCAR/May-2012.tex0000644000000000000000000000311312221362553014013 0ustar0000000000000000\documentclass{article} \usepackage{hcar} \begin{document} % Agda-NA.tex \begin{hcarentry}[section,updated]{Agda} \label{agda} \report{Nils Anders Danielsson}%05/12 \status{actively developed} \participants{Ulf Norell, Andreas Abel, and many others} \makeheader Agda is a dependently typed functional programming language (developed using Haskell). A central feature of Agda is inductive families, i.e.\ GADTs which can be indexed by \emph{values} and not just types. The language also supports coinductive types, parameterized modules, and mixfix operators, and comes with an \emph{interactive} interface---the type checker can assist you in the development of your code. A lot of work remains in order for Agda to become a full-fledged programming language (good libraries, mature compilers, documentation, etc.), but already in its current state it can provide lots of fun as a platform for experiments in dependently typed programming. The next version of Agda is under development. The most interesting changes to the language may be the addition of pattern synonyms, contributed by Stevan Andjelkovic and Adam Gundry, and modifications of the constraint solver, implemented by Andreas Abel. Other work has targeted the Emacs mode. Peter Divianszky has removed the prior dependency on GHCi and haskell-mode, and Guilhem Moulin and myself have made the Emacs mode more interactive: type-checking no longer blocks Emacs, and the expression that is currently being type-checked is highlighted. \FurtherReading The Agda Wiki: \url{http://wiki.portal.chalmers.se/agda/} \end{hcarentry} \end{document} Agda-2.3.2.2/doc/HCAR/November-2009.tex0000644000000000000000000000230512221362553015052 0ustar0000000000000000\documentclass{article} \usepackage{hcar} \begin{document} \begin{hcarentry}[updated]{Agda} \label{agda} \report{Nils Anders Danielsson}%05/09 \status{actively developed} \participants{Ulf Norell and many others} \makeheader Agda is a dependently typed functional programming language (developed using Haskell). A central feature of Agda is inductive families, i.e.\ GADTs which can be indexed by \emph{values} and not just types. The language also supports coinductive types, parameterized modules, and mixfix operators, and comes with an \emph{interactive} interface---the type checker can assist you in the development of your code. A lot of work remains in order for Agda to become a full-fledged programming language (good libraries, mature compilers, documentation, etc.), but already in its current state it can provide lots of fun as a platform for experiments in dependently typed programming. New since last time: \begin{itemize} \item Version 2.2.4 has been released. \item Agda is now available in Ubuntu. \item Darin Morrison is currently extending Cabal to support Agda code. \end{itemize} \FurtherReading The Agda Wiki: \url{http://wiki.portal.chalmers.se/agda/} \end{hcarentry} \end{document} Agda-2.3.2.2/doc/HCAR/May-2010.tex0000644000000000000000000000230612221362553014014 0ustar0000000000000000\documentclass{article} \usepackage{hcar} \begin{document} \begin{hcarentry}[updated]{Agda} \label{agda} \report{Nils Anders Danielsson}%11/09 \status{actively developed} \participants{Ulf Norell and many others} \makeheader Agda is a dependently typed functional programming language (developed using Haskell). A central feature of Agda is inductive families, i.e.\ GADTs which can be indexed by \emph{values} and not just types. The language also supports coinductive types, parameterized modules, and mixfix operators, and comes with an \emph{interactive} interface---the type checker can assist you in the development of your code. A lot of work remains in order for Agda to become a full-fledged programming language (good libraries, mature compilers, documentation, etc.), but already in its current state it can provide lots of fun as a platform for experiments in dependently typed programming. New since last time: \begin{itemize} \item Version 2.2.6 has been released, with experimental support for universe polymorphism. \item FreeBSD users can now install Agda using FreshPorts. \end{itemize} \FurtherReading The Agda Wiki: \url{http://wiki.portal.chalmers.se/agda/} \end{hcarentry} \end{document} Agda-2.3.2.2/notes/0000755000000000000000000000000012221362553012031 5ustar0000000000000000Agda-2.3.2.2/notes/fixity-declarations0000644000000000000000000003472012221362553015744 0ustar0000000000000000Suggestion for how operator fixity should be specified ------------------------------------------------------ Nils Anders Danielsson (By fixity I mean associativity and precedence.) The current scheme is a mess. With Unicode symbols and mixfix operators users (such as myself) tend to define more operators than in Haskell, and then the Haskell fixity handling is too limited. It is very hard to get an overview over a total ordering which specifies how tight every operator binds in comparison to every other. This note describes a way to avoid these problems. The solution is not perfect--some limitations are discussed towards the end--but it is quite lightweight, so it should be relatively easy to implement and try out. New approach ------------ Associativity can be specified just as before. An operator is either left associative, right associative, or nonassociative. (Note that only infix operators can be left or right associative; pre- and postfix operators are always nonassociative.) The basic idea of the new approach to precedence handling is to abandon the current total order and instead have a partial order of precedences. This is an old idea, which is easy to understand. The basic difference compared to the current scheme is that two operators of noncomparable precedence cannot be used next to each other without inserting parentheses. The only crux is to find a good way of specifying the precedences. I believe that it is a good idea if the precedence of an operator can be understood locally, so I suggest that one should only be allowed to specify precedences at the binding site (in the defining module) of an operator, conservatively extended when new operators are defined. (This rules out having "first class precedences", where the precedences of an operator are free-standing entities which can be exported and imported separately from the operators themselves.) Precedences are defined for an operator • by relating it to previously defined operators. This can be done in three ways: * infix[lr ] • binds as ∘ This means that • (which is left, right or nonassociative) binds in exactly the same way as ∘. * infix[lr ] • binds tighter-than (op₁…) looser-than (op₂…) This means that • binds strictly tighter than op₁… and strictly looser than op₂…. The two parts tighter-than (…) and looser-than (…) can be given in any order, and one of them can be omitted. This declaration is only valid if it does not change the relations of any previously declared operators, i.e., if the precedence relation before this declaration is denoted by ⊰ and the one after this declaration by ⊰′, then the following property must hold: ∀ op₁ ≠ •. ∀ op₂ ≠ •. op₁ ⊰ op₂ ⇔ op₁ ⊰′ op₂. This property ensures some degree of locality for the precedences: To see if/how two operators are related it is enough to inspect the fixity declarations of these two operators, plus those of the operators referred to in these declarations (transitively). It is impossible for an unrelated fixity declaration to change this relation. * infix[lr ] • With this declaration • becomes unrelated to all other operators. * No fixity declaration for • is the same as specifying "infix •", i.e. • becomes nonassociative and unrelated to all other operators. It should also be possible to combine the fixity declarations of several operators, for instance as follows: infixl _op₁_ _op₂_ _op₃ binds looser-than (_+_) This is equivalent to the following three declarations: infixl _op₁_ binds looser-than (_+_) infixl _op₂_ binds as _op₁_ infixl _op₃ binds as _op₁_ (Note the use of _op₁_ in the last two declarations.) Some minor details ------------------ Some minor details (as compared to the current fixity handling in Agda): * Non-operator (function) symbols should still bind tighter than everything else. * Fixity declarations should of course be scope checked, and an error given if a fixity declaration is given for an operator which is not in scope. * It should be possible to give fixity declarations to record fields, for instance as follows: infix Setoid._≈_ binds as _≡_ infixl Ring._-_ binds as Ring._+_ * I do not like the fact that, for operators of the same precedence, the following sub-order of precedence is used: * postfix * prefix * infix right associative * infix left associative * infix nonassociative As an example, take the following fixity declarations: infixr 6 _∷_ infixl 6 _+_ infix 6 -_ _! Currently they result in 5 + 6 ∷ [], - 5 + 6 and - 2 ! parsing as (5 + 6) ∷ [], (- 5) + 6 and - (2 !), even though these expressions should not parse at all. Limitations ----------- The scheme outlined above has a limitation, demonstrated by the following example: Let us say that two libraries, one for sets and one for arithmetic, are developed independently. It is probably unreasonable (if one wants to keep unrelated code separate) for one of these libraries to depend on the other. Hence expressions such as the following won't parse: a + b ∈ c. Parentheses will have to be used: (a + b) ∈ c. To me this example is not very convincing, though. If the two libraries are really separate, then there should not be _any_ connection between them. If, on the other hand, it is a requirement that _+_ should really bind tighter than _∈_, then the libraries are not unrelated, but one should import the other. Another possible problem with the scheme outlined above is its implementation. Currently mixfix operator parsing is implemented in Agda (more or less) as follows: * Expressions are first parsed as if every operator was a function symbol. This yields parse trees (rose trees) which need to be post-processed. * Operator parsing is then done as part of scope-checking. For every symbol sequence (list in the rose tree) in a parsed expression a dedicated parser is generated based on which operator parts are present in the sequence. Scope information is needed for this step, since the relative precedences of the operators and also their associativity are used to construct the parser. The symbol sequence is then parsed using this dedicated parser. It is currently unclear whether this implementation method can be made efficient for the fixity handling scheme outlined above. Conclusion ---------- If the implementation can be made efficient, then I believe that the scheme outlined above is strictly better than the one we have. It is also easy to understand. In other words, I will start thinking about the implementation. ------------------------------------------------------------------------ Improved syntax ------------------------------------------------------------------------ infix [ε|left|right] [ε|binds [as |looser than |tighter than |looser than tighter than |tighter than looser than ]] ------------------------------------------------------------------------ Refinement ------------------------------------------------------------------------ Ulf commented that the scheme above is too inflexible. If (the already existing) library A defines _+_, and library B defines _&_ (which is unrelated to _+_), then it is impossible to define _==_ in library C in such a way that _+_ binds tighter than _==_, which in turn binds tighter than _&_. In order to accommodate this, let us drop transitivity. Details (based on discussions with Ulf): Precedence relations are DAGs, whose nodes are annotated with sets of operators. Let node(•) be the node of operator • (if any), and let n₁ ⊰ n₂ mean that there is an edge from node n₁ to node n₂. Fixity declarations get the following meanings: • binds as ∘: • is added to node(∘). • binds looser than ∘₁ tighter than ∘₂: A new node annotated with {•} is added, plus an edge from node(∘₁) and an edge from node n for all n with n ⊰ node(∘₁), plus an edge to node(∘₂) and an edge to node n for all n with node(∘₂) ⊰ n. Note that this does not create any new dependencies between ∘₁ and ∘₂, but • inherits earlier dependencies. A precedence relation now gives rise to a context free grammar in the following way: * The top-level production is as follows: expr ∷= | ⋁ {n | n is a node in the graph} * For every node n the following productions are added: n ∷= prefix-op⁺ n↑ | n↑ postfix-op⁺ | n↑ infix-non-assoc-op n↑ | (n↑ infix-left-assoc-op)⁺ n↑ | n↑ (infix-right-assoc-op n↑)⁺ n↑ ∷= | ⋁ {n' | n ⊰ n'} x-op ∷= ⋁ {op-prod | op is an "x" operator annotating n} op-prod ∷= op₁ expr op₂ expr op₃ … op_n (where op_i are the name parts of the mixfix operator op) Note that if all operator name parts are unique, and s don't introduce any ambiguity, then the grammar is unambiguous. However, we don't want to require all operator name parts to be unique, since this can be rather inflexible. (Consider a DSEL containing both if_then_ and if_then_else_, for instance. Or the two operators ⟦_⟧_ and ⟦_⟧'_.) All ambiguous parses will be rejected, in many cases with an error message listing all possible parses: Ambiguous parse. Could mean any of the following: if x then (if y then a) else b if x then (if y then a else b) We expect there to be rather few cases of ambiguity. A large number of potentially ambiguous operators will make it harder to write syntactically correct programs, and programmers will presumably be reluctant to subject themselves to this situation. ------------------------------------------------------------------------ Sections ------------------------------------------------------------------------ We can also support sections. Some examples will outline how this can be accomplished: If we have _+_ : ... then 5 +_ and _+ 3 are sections. They stand for \x -> 5 + x and \x -> x + 3, respectively. Note that +_ becomes a postfix operator, and _+ a prefix operator. Note also that _+_ can be viewed as a section, and does not need to be treated as a special case. (The qualified variant M._+_ still needs special treatment, though.) All mixfix operators can be sectioned. For instance, if we have if_then_else_ : ... then if_then x else y stands for \b -> if b then x else y. Parsing of sections is accomplished by letting the lexer distinguish different uses of '_': * As a wildcard. * At the beginning of an operator. * In the middle of an operator. * At the end of an operator. The different uses can be distinguished by examining surrounding white space. ------------------------------------------------------------------------ Open questions ------------------------------------------------------------------------ * What is the sub-class of DAGs that the declarations introduced above can give rise to? Not all DAGs can be constructed in this way. Take •⟶•⟶•⟶•, for instance. Could this be overly limiting? * Does the order of the declarations matter? If it does, then the scheme should be changed, since otherwise we would have a non-declarative language for specifying fixities. (It would not be very nice if the relative precedence of two operators depended on in which order two modules were imported, for instance.) Order does not matter for this simple example: infix _≡_ infix left _+_ binds tighter than _≡_ infix ¬_ binds looser than _≡_ The declarations give rise to the following precedence graph: ╭─────╮ │ _+_ ├⟵╮ ╰──┬──╯ │ ↑ │ ╭──┴──╮ │ │ _≡_ │ │ ╰──┬──╯ │ ↑ │ ╭──┴──╮ │ │ ¬_ ├─╯ ╰─────╯ If the order of the declarations is changed to infix _≡_ infix ¬_ binds looser than _≡_ infix left _+_ binds tighter than _≡_ we still get the same graph. Is this generally true? ------------------------------------------------------------------------ Summary of important "correctness" criteria ------------------------------------------------------------------------ • Adding a new declaration should not change the relations between previously declared operators. • If declarations can be reordered, then the semantics must be independent of their order. ------------------------------------------------------------------------ A possible problem with the scheme above ------------------------------------------------------------------------ Consider the following (Agda-like) modules: module A where infix _*_ module B where import A infix _^_ binds tighter-than (_*_) module C where import A infix _+_ binds looser-than (_*_) module D where import B; import C In D, do we have node(_+_) ⊰ node(_^_)? If not, then order of declarations does (in some sense) matter, since putting the two declarations in the same module would lead to a different result. However, if we do have node(_+_) ⊰ node(_^_), then the relationship between the two operators is not fixed until they are brought into the same scope. Neither scenario feels appealing. ------------------------------------------------------------------------ Refinement of the refinement ------------------------------------------------------------------------ I am compelled to remove the transitivity emulation from fixity declarations. It is too hard to understand. To start with we can require the user to specify every relationship explicitly. If this should turn out to require too much work, then the following extensions seem promising: • One could invent some notation for specifying the fixity of several operator groups at once, for instance: infix (_+_ _-_) < (_*_ _/_) < (_^_) The different groups in this kind of declaration would be transitively related. • One could specify a /module/ in an operator list; this would stand for all the operators exported from the module (top-level, plus perhaps records). Note that this may be a bit coarse. If Agda's open public was more like Haskell's re-exports, then it would be easy to use the module system to package operators for inclusion in fixity declarations, though. Agda-2.3.2.2/notes/classes0000644000000000000000000001366012221362553013417 0ustar0000000000000000------------------------------------------------------------------------ Notes after class discussion 2007-08-17 (Ulf, NAD) These are just some quick and dirty notes outlining the outcome of the discussion. The use cases motivating the choices done are not discussed. Class declarations: record class C Γ : Δ where ... data class C Γ : Δ where ... No restrictions on parameters or indices. Instance declarations: f : ... f = ... instance f or perhaps instance f : ... f = ... f and the instance declaration have to be in the same scope. The instance which f declares is not in scope (with respect to instance search, see below) in the type signature of f, but it is in scope in the body of f (perhaps). The type of f has to evaluate to the normal form Γ -> C Δ, where C is a class. Γ has to consist solely of: • variables which are "rigid" in Δ (arguments to type constructors), and/or • class type constructors applied to arbitrary arguments. Denote these by C' Δ'. The type of f gives rise to a rewrite rule: C Δ -> C' Δ' (With an empty RHS if C' Δ' is empty.) The collection of all instance rewrite rules always has to be terminating. For every new instance added the termination checker is run on the rewrite rules (treating data/record type constructors in Δ/Δ' as constructors). One could also imagine a more local variant, in which the "recursive calls" in the RHS always have to be strictly structurally smaller than the LHS arguments. We may also allow higher-order types, in which case the RHSs become higher-order and the positive occurrences in C' Δ' should be inspected by the termination checker. Superclass declarations: record class C₁ Γ : Δ -> Setⁿ where ... instance x : C₂ X ... C₂ has to be a class; C₂ X becomes a superclass of C₁ Γ Δ. Searching for instances: If ? : C Γ, where C is a class, then ordinary unification is not used. Instead a special instance search is performed. The instance search is performed in several "levels". First a match for C Γ is searched for. If several matches are found, an error is emitted (ambiguous instances). If exactly one match is found, that match is bound to the meta variable. And if no matches are found, the search continues with the superclasses of C Γ, in a breadth-first manner. (First all immediate superclasses, all at the same time. Then the next level, and so on.) The search at a specific level is done in the following way: ⑴ All instances in scope are collected. Locally bound arguments whose types are of the form outlined for instances above also count as instances. ⑵ The rewrite rules generated by the instances are applied to the goals at hand (for instance C Γ), yielding new goals. This is repeated until no rules apply any more. Due to the termination checking done we know that this will terminate (right?). ⑶ All successful matches (search trees whose leaves all correspond to empty RHSs) are collected. From a successful match a dictionary can be built by applying the instance functions in a way corresponding to the resulting search tree; all arguments to these functions are either given by the goal at hand (the rigid variables) or by the children in the search tree. ------------------------------------------------------------------------ A class system -------------- what can be a class? - any datatype/record what is an instance? - an element of a class (possibly parameterised) - parameterised by what? + other instances clearly + non-instances? yes, arguments to the classes some examples: class Eq (A : Set) : Set where eq : (_==_ : A -> A -> Bool) -> Eq A instance eqList : {A : Set} -> Eq A -> Eq (List A) eqList eqA = .. what are the restrictions on an instance declaration? - should probably be instance i : Δ -> Cs -> C ts where Cs are classes Δ can be inferred from C ts - instance search will proceed as follows: + given a goal C ss, unify with C ts to get ρ (deciding all of Δ) + the new goals are Cs ρ multiparameter type classes? - how difficult? - necessary? clearly useful (at least with inductive families) functional dependecies - probably not needed (we have associated types for free) zero parameter type classes are useful: class True : Set where instance tt : True A constructor can be declared an instance by writing instance before the name. The normal checks are applied to the type. _/_ : (n m : Nat) -> {m ≠ 0} -> Nat m / n = .. now x / 3 requires a proof of 3 ≠ 0 = True for which there is an instance (tt). This would work with an inductive definition of ≠ as well (but requires multiparameter classes): class _≠_ : Nat -> Nat -> Set where instance neqZS : {m : Nat} -> 0 ≠ suc m instance neqSZ : {n : Nat} -> suc n ≠ 0 instance neqSS : {n m : Nat} -> n ≠ m -> suc n ≠ suc m How to do super classes? class Ord (A : Set){eqA : Eq A} : Set where ord : (compare : A -> A -> Ordering) -> Ord A {eqA} instance ordNat : Ord Nat ordNat = ord compareNat this doesn't really work... sort : {A : Set} -> {Ord A} -> List A -> List A there is no instance Eq A here. Ord A must contain Eq A class Ord (A : Set) : Set where ord : {Eq A} -> (compare : A -> A -> Ordering) -> Ord A how to get the Eq dictionary from the Ord dictionary (nothing recording the relationship here). One attempt: instance ordToEq : {A : Set} -> Ord A -> Eq A ordToEq (ord eq _) = eq How does this work with other instances (clearly overlapping)? Maybe there is a good reason it's treated specially in Haskell... It would be nice not to have to introduce more syntax. Finding instances ----------------- Instances form a rewriting system (there is a paper about this stuff...) instance i : Δ -> Cs -> C ts corresponds to a rule ∀ Δ. C ts --> Cs vim: sts=2 sw=2 tw=80 Agda-2.3.2.2/notes/scope0000644000000000000000000001345412221362553013074 0ustar0000000000000000 The discussion below is a transcript of my thinking process. This means that it will contain things that were true (or I thought were true) at the time of writing, but were later revised. For instance, it might say something like: the canonical form of @x@ is @x@, and then later say that it is @A.x@. What should the scope analysis do? One option would be to compute some of the name space stuff, making all names fully qualified. How does this work for parameterised modules? We keep namespace declarations and imports, but throw away open declarations. We also remove all import directives. > module A (X : Set) where > > f = e > g = .. f .. -- what is the fully qualified name of f? @f -> A.f@. In parameterised modules you get a name space with the name of the module: > module A (X : Set) where > namespace A = A X > module A where > f = e > namespace A' = A > g = e' > h = A' g -- is this valid? no. A' is a snapshot of A Example name space maps > import B, renaming (f to g) -- B : g -> B.f > namespace B' = B, renaming (g to h) -- B' : h -> B.f > open B', renaming (h to i) -- local: i -> B.f With parameterised modules > import B -- B/1 : f -> _ > namespace B' = B e -- B' : f -> B'.f The treatment of namespace declarations differ in the two examples. Solution: namespace declarations create new names so in the first example @B': h -> B'.h@? We lose the connection to B, but this doesn't matter in scope checking. We will have to repeat some of the work when type checking, but probably not that much. Argh? The current idea was to compute much of the scoping at this point, simplifying the type checking. It might be the case that we would like to know what is in scope (for interaction\/plugins) at a particular program point. Would we be able to do that with this approach? Yes. Question marks and plugin calls get annotated with ScopeInfo. Modules aren't first class, so in principle we could allow clashes between module names and other names. The only place where we mix them is in import directives. We could use the Haskell solution: > open Foo, using (module Bar), renaming (module Q to Z) What about exporting name spaces? I think it could be useful. Simple solution: replace the namespace keyword with 'module': > module Foo = Bar X, renaming (f to g) Parameterised? > module Foo (X : Set) = Bar X, renaming (f to g)? Why not? This way there the name space concept disappear. There are only modules. This would be a Good Thing. Above it says that you can refer to the current module. What happens in this example: > module A where > module A where > module A where x = e > A.x -- which A? Current, parent or child? Solution: don't allow references to the current or parent modules. A similar problem crops up when a sibling module clashes with a child module: > module Foo where > module A where x = e > module B where > module A where x = e' > A.x In this case it is clear, however, that the child module shadows the sibling. It would be nice if we could refer to the sibling module in some way though. We can: > module Foo where > module A where x = e > module B where > private module A' = A > module A where x = e' > A'.x Conclusion: disallow referring to the current modules (modules are non-recursive). What does the 'ScopeInfo' really contain? When you 'resolve' a name you should get back the canonical version of that name. For instance: > module A where > x = e > module B where > y = e' > -- x -> x, y -> y > -- B.y -> B.y > ... What is the canonical form of a name? We would like to remove as much name juggling as possible at this point. Just because the user cannot refer to the current module doesn't mean that we shouldn't be able to after scope analysis. > module A where > x = e > module B where > y = e' > -- * x -> A.x > -- * y -> A.B.y > -- * B.y -> A.B.y > import B as B' > -- * B'.x -> B.x > import C > module CNat = C Nat > -- * CNat.x -> A.CNat.x Argh! This whole fully qualified name business doesn't quite cut it for local functions. We could try some contrived naming scheme numbering clauses and stuff but we probably want to just use unique identifiers (numbers). It would still be useful to keep the fully qualified name around, though, so the work is not completely in vain. How does this influence interfaces and imported modules? Consider: > module A where x = e > module B where > import A > y = A.x > module C where > import A > y = A.x > module D where > import B > import C > h : B.y == C.y > h = refl It would be reasonable to expect this to work. For this to happen it's important that we only choose identifiers for the names in A once. Aside: /There is another issue here. A.x has to be available during type checking of D (for computations) even though it's not in scope/. That might actually hold the key to the solution. We need to read interface files for all modules, not just the ones needed for their scope. In other words interface files must contain references to imported modules. There's still the question of when to assign unique identifiers. At the moment, scope checking and import chasing is intertwined. We would have to keep track of the files we've generated uids for and check for each import whether we need to generate new names. How about the type signatures and definitions in the interface files? Maybe it would be easier to come up with a way of naming local functions and just stick to the fully qualifed names idea... Or, we could go with qualified unique identifiers. A (qualified) name has two uids: one for the top-level module (file) and one for the name. That way we can generate uids once and store them in the interface file and we only have to generate uids for new modules, or maybe just stick with the module name as the uid for the time being. Agda-2.3.2.2/notes/separate-typechecking0000644000000000000000000000553212221362553016240 0ustar0000000000000000 When and how to create/read interface files ------------------------------------------- We need information from imports twice: at scope checking, and at type checking. We can go about this in a few different ways: - read interface file twice, first at scope checking (possibly creating it) and second at type checking - read the interface once, and store the type information for use at type checking time Other concerns -------------- - What happens when we do import from inside a parameterised module? Top-level modules can be parameterised. - The imported module exists outside the parameterised module, so it shouldn't be affected by the parameters. - Can we do imports anywhere? Does it make sense. Probably, but is it a good thing? Options: - imports anywhere - only in top-level module - only first in top-level module (Haskell-style) - before the top-level module (java-style) Let's stick with imports anywhere for the time being. Technical issues ---------------- - How should it work? - The interface file simply stores a representation of the internal state (ScopeInfo and Signature). When importing a module we just read the interface file and merge the corresponding internal thing into the current state. - We need to keep track of what things come from the current module, and what things come from imported modules. In the final version we don't want to store things from an imported module in the interface for a module. But rather store a reference to the imported module. This of course means that reading an interface file might require the reading of other interface files. We need cycle detection. - First step should be to change the Signature and ScopeInfo to account for imported modules, making sure we recognise what's part of the current module and what is imported. - In scope checking we need to store the ModuleScope. This means that there should be a function to extract the ModuleScope of the current module from the ScopeInfo. - Now what? Making the type checking monad aware of imports: - separate signatures for imported modules and other modules - look up things in both signatures. exactly one lookup must succeed. - we play around with the signature in a lot of places? what needs to be changed to handle the imported signature? don't know, i guess we'll see... - What does the interface file need to contain? - ModuleScope - Signature - BuiltinThings - names of imported modules - Issues - primitive functions: we can't store type-checking computations in the interface file. So we need a different representation. What? - remember which module have been imported, so that we don't load the same interface several times. Or don't care? If we want to check for clashes we might want to do this. vim: tw=80 sts=2 sw=2 fo+=t com=f\:- Agda-2.3.2.2/notes/thinkingAloud0000644000000000000000000002233012221362553014554 0ustar0000000000000000 Topic: Modules Topic: Structure of the signature. * The module system is hierarchical so it seems resonable to structure the signature accordingly. * We need to be able to look up a QName in the signature. * Why does it have to be hierarchical? When do we need to manipulate an entire subtree? * A problem is that QNames aren't well thought out yet. Currently a moduleId is a concrete name. That's not very good. * Let's make it flat for the time being, that should be a simple thing to change at a later stage. * We would also have to think about what happens when modules are instantiated (module Foo = Bar Nat), but that can also be postponed. EndTopic Topic: Parameterised modules * Turns out to be a major headache to keep track of free variables. * We need to structure things nicely. * Attempt 1: Hierarchical signature. notes/ModulesAttempt1.hs Not necessary(?) * Attempt 2: Flat signature notes/Modules.hs EndTopic Topic: Rewriting for abstract things * Remark by Andreas during the video talk Would it be possible to add rewriting rules for definitional equalities which hold inside a module (where we know the values of abstract things) when working outside the module? Example: module Stack where abstract Stack : Set -> Set Stack = List push : A -> Stack A -> Stack A push = cons pop : Stack A -> Maybe (Stack A) pop nil = nothing pop (x::xs) = just xs rewrite pop (push x s) == just s The type of the rewrite should be checked without knowing the definitions and the left-hand-side and the right-hand-side should be convertible when knowing the definitions. EndTopic EndTopic Topic: Local functions Topic: Functions as parameterised modules * Remark by Conor during the video talk It would be nice to have a parameterised module containing all the local definitions for each definition. This way you could actually refer to the local functions by instantiating this module. f : (x:A) -> (y:B) -> C f x y = e where g : (z:C) -> D g z = e' would mean something like module f (x:A)(y:B) where g : (z:C) -> D g z = e' f : (x:A) -> (y:B) -> C f x y = e where module Local = f x y open Local Open problem: How to handle definitions with multiple clauses? EndTopic Topic: Lifting * Remark by Makoto during the video meeting When lifting local definitions you might not want to abstract over all variables in the context, but only those which are in scope. Example: foo x y z = bar y where bar true = true bar false = z Abstracting over all variables gives the following: lift_bar x y z true = true lift_bar x y z false = z foo x y z --> lift_bar x y z y foo x' y z --> lift_bar x' y z y So foo x y z != foo x' y z, even though foo never uses its first argument. If we instead abstract only over things that are actually used we get: lift_bar z true = true lift_bar z false = z foo x y z --> lift_bar y z foo x' y z --> lift_bar y z EndTopic EndTopic Topic: Pattern Matching Topic: Berry's majority function * Remark by Conor during the video talk: We won't be able to satisfy all equations of Berry's majority function definitionally in the core language, so if we do that in the full language we are in trouble. maj T T T = T maj T F x = x maj F x T = x maj x T F = x maj F F F = F Possible solution: Match patterns left-to-right, as soon as there is an inconclusive match the whole matching is inconclusive. Example: f T F = F f _ _ = T With the standard approach we have f x T --> T but instead we say that this doesn't reduce (since x is blocking the pattern T in the first clause). With this approach order does matter! Are there any problems? Example: f x 0 = 1 f 0 (s y) = y f (s x) (s y) = x With left to right matching we still have f x 0 --> 1, but the tranlation will yield(?) f 0 = \y -> f1 y f (s x) = \y -> f2 x y f1 0 = 0 f1 (s y) = y f2 x 0 = 1 f2 x (s y) = x That is pattern matching first on the first argument. So f x 0 will not reduce. Hm. Can we figure out the correct order in which to pattern match? Maybe. We can decide in which order to pattern match by scanning the clauses left to right, top to bottom. The first constructor pattern appears (in the example) in the second argument of the first clause, so we should start by matching on the second argument. EndTopic EndTopic Topic: Meta variables Topic: Meta variable dependencies and hidden application * Currently meta variable dependencies are represented as applications. This means that they contain hiding information. * Is this a problem? It does clutter up some things, but on the other hand it's possible that a meta variable _is_ applied to an hidden argument. EndTopic Topic: Sort meta variables * How can we solve them? * When do we have to? * One option could be to instantiate all unsolved (unconstrained) sort metas to Set. EndTopic Topic: Dependency juggling * Juggling parameters is a mess. There is a dire need for a nice clean API. EndTopic Topic: Scope * Meta variables need to be scope checked (probably) so when creating a new meta we should have access to scope information. It'll probably be enough to annotate declarations with scope and make sure that the type checker updates the current scope when passing a definition. Not having to bother with lambda bound things makes it easier. In any case interaction points need to have their scope. This we have when type checking (and thus when creating the meta). EndTopic Topic: Question mark numbers * We probably want to separate the numbers on question marks from those on underscores. * Possible solution: - generate question mark numbers during scope checking - generate MetaIds as before (both underscores and question marks) - keep a map from question mark numbers to meta ids - the interface will use question mark numbers EndTopic EndTopic Topic: Implementation details Topic: Representation Topic: Unique names in abstract syntax. * The names of local functions can clash and it's not clear how to disambiguate them if names are (qualified) strings. * So unique identifiers (numbers) for names sounds like a good idea. * Problem: Module system, in particular separate type checking and interface files. If names are identified by globally unique numbers we're in trouble. * Solution: qualified unique numbers. A name is a pair of a module and a unique number. * Question: How qualified (top-level modules or also sub-modules)? * Answer: It feels better to treat top-level modules and sub-modules the same as far as possible, so each module (including sub-modules) should have its own set of unique identifiers. EndTopic Topic: Module names vs. function names * Since there is no confusion between module names and function names (they can never appear in the same place) it makes sense to have different representations for them. For clarity if nothing else. EndTopic Topic: n-ary application in terms. * Some things might be simpler with binary application. Check it out. EndTopic EndTopic Topic: Generics * How much do we gain by the generics? Is it worth it? * Maybe there is a more light-weight approach. EndTopic Topic: Debugging * How to make debugging smooth? * We need different levels of information in print-outs. EndTopic Topic: Figuring out what's in Syntax.Internal(New) * type Args = [Value] * xxx2str :: xxx -> Reader Int String Generates fresh names. * Values can be beta redexes. Why? Maybe it will allow a better reduction strategy than call-by-name. I'm not sure it matters. * instance Eq Value. Only variables can be equal. Not very nice. Make a type wrapper (or define another function). * addArgs = flip apply (but generically) * data Sort = ... | Lub Sort Sort -- do we need this? * data TCErr = Fatal String | PatternErr MId This is nice. Pattern unification failure might go away if we wait a bit, PatternErr is used to signal such a failure. * reduce is parameterised by the stuff that's in the monad. This will probably make it more efficient than if it had been monadic. We can do this since it'll never change the state. EndTopic Topic: Module structure of the type checker - Syntax - Internal - TypeChecker - TypeChecking/ - Conversion - Reduce - Monad Where to put subst and adjust? Let's put them in Reduce for the time being. No, that doesn't quite work. They'll have to go in Substitute. EndTopic EndTopic Topic: TODO * Check that meta variables have been solved at appropriate times. * Keep the type on instantiated interaction meta variables. Also remember which metas are interaction points and which are go figures after instantiation. * Meta variable scope (see Meta variables - Scope). EndTopic vim: sts=2 sw=2 tw=70 fdm=marker foldmarker=Topic\:,EndTopic Agda-2.3.2.2/notes/inductive-families0000644000000000000000000001415112221362553015537 0ustar0000000000000000 Some notes on inductive families -------------------------------- ** Syntax The syntax for patterns which are instantiated by type checking (instantiated or dot patterns) is ".p". For instance, subst .x x refl px = px or map .zero f [] = [] map .(suc n) f (x :: xs) = f x :: map n f xs In the second example there's some subtle things. The n looks as though it's bound in the dot pattern. This is impossible since the dot patterns will be thrown away after type checking. What should happen is that the hidden argument to _::_ gets the name n and that's where the binding happens. This poses a problem for scope checking. The dot pattern can be an arbitrary term, but it might contain unbound variables. The scope checker will have to bind unbound variables. Maybe that's not a problem? The problem is: how to implement scope checking without copy-pasting between the ToAbstract instance and the BindToAbstract instance for expressions? Generalising a bit does the trick. Come to think of it, binding variables in dot patterns is a bad idea. It makes the type checking much harder: how to type check a dot pattern (in which context). So the cons case above will have to be one of these two: map .(suc _) f (x :: xs) = f x :: map _ f xs map .(suc n) f (_::_ {n} x xs) = f x :: map n f xs ** Type checking Step 0: Type checking the datatype Nothing strange. We just lift some of the previous restrictions on datatypes. Step 1: Type checking the pattern Two interesting differences from the ordinary type checking: addFirstOrderMeta (α : A) ───────────────────────── same for dot patterns Γ ⊢ _ : A --> Γ ⊢ α, α c : Δ -> Θ -> D xs ss' Γ ⊢ ps : Θ[ts] --> Γ' ⊢ us, αs Γ' ⊢ ss = us : Θ[ts] ────────────────────────────────────────────────────────────────────────────── Γ ⊢ c ps : D ts ss --> Γ' ⊢ c ts us, αs Interaction between first order metas and η-expansion? Suppose data D : (N -> N) -> Set where id : D (\x -> x) h : (f : N -> N) -> D f -> .. h _ id Now we have to check α = \x -> x : N -> N which will trigger η-expansion and we'll end up with α x = x : N which we can't solve. We'll ignore this for now. Possible solution could be to distinguish between variables introduced by η-expansion and variables bound in the pattern. Step 2: Turn unsolved metas into bound variables - make sure that there are no unsolved constraints from type checking the patterns (if so, fail) - we need to remember where the first order metas come from, or at least the order in which they are generated, so type checking should produce a list of first order metas - how to get the context in the right order? explicit variables have been added to the context but not implicit ones. we should probably make sure that the final context is the right one (otherwise reduction will not work properly). - example: f y _ (cons _ x xs) the context after type checking is (y x : A)(xs : List A) with meta variables (α β : N), where α := suc β. We'd want the final pattern to be f y .(suc n) (cons n x xs) and the context in the right hand side (y : A)(n : N)(x : A)(xs : List A). Solution: - pull out the context (y x : A)(xs : List A) and the meta context (α := suc β : N)(β : N) and traverse the pattern again, building the right context, instantiating uninstantiated metas to fresh variables. Quick solution: - re-type check the pattern when we know which patterns are dotted and which are variables. This also gets rid of (some of) the tricky deBruijn juggling that comes with the first-order metas. - Problem: when we say subst ._ _ refl could this mean subst x .x refl ? Answer: no, an explicit underscore can never become dotted. But there is a similar problem in tail ._ (x :: xs) Here we might instantiate the hidden length in the _::_ rather than the dotted first argument. So we need to keep track of first-order metas that 'wants' to be instantiated, and instantiate those at higher priority than others. Why is this a problem? The user won't be able to tell (at least not easily) that she got tail n (_::_ .{n} x xs) rather than tail .n (_::_ {n} x xs) The problem is rather an implementation problem. We want to check that dotted patterns actually get instantiated, and give an error otherwise. How would we distinguish this case from the bad cases? Step 3: Type check dot patterns and compare to the inferred values * after step 2 the context will be the correct one. * where do we find the type to check against? look at the meta variables generated during type checking So, - traverse the pattern with the list of meta-variables - for each dot pattern, + look up the type of the corresponding meta + and check that it's equal to the meta-variable A BETTER SOLUTION ───────────────── Context splitting a la Thierry. For each clause, generate a case tree. Each case is an operation on the context: (case x of C ys : D ss -> t) corresponds to (Δ₁, x : D ts, Δ₂) ─→ (Δ₁, ys : Γ, Δ₂[C ys/x])σ where σ = unify(ss, ts) So to type check a clause: ∙ generate case tree ∙ perform the context splitting (remembering the substitutions σ) ∙ verify that σ corresponds exactly to the dotted patterns Questions: ∙ what is the unification algorithm? ∙ what argument to split on? ∙ first constructor pattern? Consider: data D : Set -> Set where nat : D Nat bool : D Bool f : (A : Set) -> A -> D A -> X f .Nat zero nat = x Here we can't split on zero first, since the type is A. ∙ first constructor pattern whose type is a datatype error if there are constructor patterns left but no argument can be split vim: tw=80 sts=2 sw=2 fo=tcq Agda-2.3.2.2/notes/releases0000644000000000000000000000440412221362553013561 0ustar0000000000000000When releasing a new version of Agda, the following procedure can be followed: * Get a clean Agda repository. darcs get http://code.haskell.org/Agda/ Agda.release cd Agda.release * Finish the release notes in doc/release-notes/.txt. * Update the README, if necessary. * Update the version numbers in Agda.cabal (twice) and src/data/emacs-mode/agda2-mode.el. * Add a second source-repository section to Agda.cabal: source-repository this type: darcs location: http://code.haskell.org/Agda/ tag: * Remove -Werror from Agda.cabal. (Agda uses code generated by Cabal, Paths_Agda, and under some configurations this code gives rise to warnings.) * Ensure that cabal haddock works: cabal configure && cabal haddock * Ensure that the Emacs mode can be compiled without errors or warnings (except for the "cl package required at runtime" warning): (cd src/data/emacs-mode && \ emacs --batch -L . -f batch-byte-compile *.el; \ rm -f *.elc) * Tag and build source distributions. (Do not forget to record the changes above first.) VERSION= darcs tag $VERSION cabal configure && cabal sdist && cabal check cabal install darcs dist --dist-name=Agda-$VERSION * Ensure that all the packages build properly. BASE=`pwd` cd ${TMPDIR:-/tmp} tar xzf $BASE/Agda-$VERSION.tar.gz cd Agda-$VERSION make install CABAL_OPTIONS="--prefix=$PWD/usr" autoconf ./configure make test tar xzf $BASE/dist/Agda-$VERSION.tar.gz cd Agda-$VERSION cabal install cd .. Do not forget to test the Emacs mode. * Upload the Cabal package using cabal upload. cd $BASE cabal upload dist/Agda-$VERSION.tar.gz * Upload the darcs tar-ball to code.haskell.org. scp Agda-$VERSION.tar.gz code.haskell.org:/srv/code/Agda/ * Update the download page on the Agda Wiki. * Announce the release of the new version on the Agda mailing list. * Update the version numbers again, so that released and development versions are not confused, and remove the "this" source-repository section from the Cabal file. (This would be unnecessary if we had two repositories, one stable and one for development.) * Push all changes. darcs push Agda-2.3.2.2/notes/builtin0000644000000000000000000000525312221362553013427 0ustar0000000000000000 Built-in things --------------- - Where are they defined? + Haskell-module? Not so nice. Hard to find out what's predefined. + Agda2 prelude Nicer, but what would this look like? - How are they accessed? + Problem in Agda 1: Bool already defined. + import Prelude / import Builtin ? - Could we use a more general FFI? + Maybe.. but requires more work (hs-plugins, or the like) Literals/sugar -------------- - What does sugar expand to? When? - What is the type of a literal? + Where is it specified? + Pragmas? {-# LITERAL NATURAL is PRIMITIVE Integer #-} {-# LITERAL LIST is SUGAR nil, (::) #-} Nice, because we can allow either sugar or builtin for some types (like strings or naturals): {-# LITERAL NUMBER is PRIMITIVE Integer #-} or {-# LITERAL NUMBER is SUGAR FOR zero, suc #-} Builtin: NATURAL, FLOAT, CHAR, STRING Possible solution ----------------- - Add a primitive keyword: + primitive integerPlus : Integer -> Integer -> Integer - Add "primitive" definitions: + data Defn = ... | Primitive Arity ([Term] -> TC Term) + The function is responsible for normalising its arguments if needed. - Primitive functions are defined in TypeChecking.Primitive + primitives :: Map String (Arity, [Term] -> TC Term) primitives = Map.fromList [ "integerPlus", (2, integerPlus) , ... ] integerPlus :: [Term] -> TC Term integerPlus [x, y] = do (x,y) <- normalise (x,y) case (x,y) of (LitInt n, LitInt m) -> return $ LitInt $ n + m _ -> ... integerEquals (Lit n) (Lit m) | n == m = primTrue primTrue :: TC Term primTrue = lookupPrim "TRUE" - Define a prelude/builtin module {-# BUILTIN NATURAL Integer #-} {-# BUILTIN FLOAT Float #-} {-# BUILTIN CHAR Char #-} postulate Integer : Set Float : Set Char : Set {-# SUGAR LIST nil :: #-} data List (A:Set) : Set where nil : List A (::) : A -> List A -> List A {-# SUGAR STRING nil, (::) #-} String : Set String = List Char {-# BUILTIN FALSE false #-} {-# BUILTIN TRUE true #-} data Bool : Set where false : Bool true : Bool primitive integerPlus : Integer -> Integer -> Integer integerEqual : Integer -> Integer -> Bool postulate integerPlusAssoc : (x,y,z:Integer) -> Built-in things and Parameterised Modules ----------------------------------------- What is the type of 1 in the following example: module Int (I:Set) where {-# BUILTIN INTEGER I #-} postulate Int1 : Set Int2 : Set module Int1 = Int Int1 module Int2 = Int Int2 Possible solution: don't allow BUILTIN in parameterised modules. vim: sts=2 sw=2 tw=80 Agda-2.3.2.2/notes/records0000644000000000000000000000172212221362553013417 0ustar0000000000000000 What do we want? ──────────────── ∙ declaration syntax record Point : Set where x : Nat y : Nat ∙ constructor record { x = 4; y = 2 } ∙ projection functions dist = x p ^ 2 + y p ^ 2 ∙ open open module P = Point p dist = sqrt (x ^ 2 + y ^ 2) ∙ η p ≡ record { x = x p; y = y p } ∙ pattern matching f (record { x = suc n }) = n ∙ record update syntax how? record p { x = zero } ? Schedule ──────── First ∙ declaration systax ∙ constructor ∙ projection functions ∙ open Next ∙ η Later ∙ pattern matching ∙ update syntax What does it mean? ────────────────── data Point : Set where : (x : Nat)(y : Nat) -> Point module Point (p : Point) where x : Nat x = y : Nat y = Issues ────── ∙ mutual records? yes will it be a problem? probably not Agda-2.3.2.2/notes/kit0000644000000000000000000000067512221362553012553 0ustar0000000000000000 By making dictionaries explicit we might be able to unify instantiate, instantiateFull, reduce and normalise. class HasKit a where applyKit :: Kit m -> a -> m a data Kit m = Kit { termKit :: TermKit m , typeKit :: TypeKit m , listKit :: ListKit m ... } type ListKit m = forall a. HasKit a => Kit -> [a] -> m [a] data TermKit m = TermKit { varKit :: Nat -> Args -> m Term , lamKit :: Hiding -> Abs Term -> m Term ... } Agda-2.3.2.2/notes/.cvsignore0000644000000000000000000000000712221362553014026 0ustar0000000000000000.*.swp Agda-2.3.2.2/notes/named-implicit0000644000000000000000000000252612221362553014655 0ustar0000000000000000 It should be possible to refer to implicit arguments by name, to avoid having long sequences of {_}. Given f : {...}{A:Set} -> ... you should be able to say f {A = Nat} to give A explicitly. This should also work in patterns: f {A = A} = .. A .. How will this work exactly? At the moment we have the judgement form (checkArgs) Γ ⊢ es fits A ↓ vs with rules Γ ⊢ e ↑ A ─→ v Γ ⊢ es fits B[v/x] ---------------------------------- Γ ⊢ e es fits (x:A)B ─→ v vs Γ ⊢ e es fits B[α/x] ---------------------------- Γ ⊢ e es fits {x:A}B ─→ α vs Γ ⊢ e ↑ A ─→ v Γ ⊢ es fits B[v/x] ---------------------------------- Γ ⊢ {e}es fits {x:A}B ─→ α vs Γ ⊢ ∙ fits B[α/x] ─→ vs ----------------------------- Γ ⊢ ∙ fits {x:A} -> B ─→ α vs To this we add the rules Γ ⊢ e ↑ A ─→ v Γ ⊢ es fits B[v/x] ---------------------------------- (same as the {e}es rule) Γ ⊢ {x=e}es fits {x:A}B Γ ⊢ {x=e}es fits B[α/y] ─→ vs ------------------------------- (x ≠ y, similar to the 'e es fits {x:A}B' rule) Γ ⊢ {x=e}es fits {y:A}B ─→ α vs What about patterns? It would work exactly the same. I.e two new rules very similar to the '{p}ps' and 'p ps : {x:A}B' rules. Agda-2.3.2.2/notes/mixfix0000644000000000000000000000056012221362553013261 0ustar0000000000000000 The idea to handle mix-fix operators is to - parse applications as lists of expressions. For instance: 1 + 2 * 3 will be parsed as [1,+,2,*,3] We then generate a parser for the operators in scope and try to parse the application. In this example the grammar would look something like this: e0 ::= e0 + e1 | e1 e1 ::= e1 * e2 | e2 e2 ::= other Agda-2.3.2.2/notes/with0000644000000000000000000000116212221362553012727 0ustar0000000000000000 data Compare : Nat -> Nat -> Set where same : {x : Nat} -> Compare x x less : {x : Nat}(y : Nat) -> Compare x (x + suc y) more : {x : Nat}(y : Nat) -> Compare (x + suc y) x _-_ : Nat -> Nat -> Nat x - y | compare x y x - .x | same = zero x - .(x + suc y) | less y = zero .(x + suc y) - x | more y = suc y -- What does it mean? _-_ : Nat -> Nat -> Nat x - y = aux x y (compare x y) where aux : (n m : Nat) -> Compare n m -> Nat aux x .x same = zero aux x .(x + suc y) (less y) = zero aux .(x + suc y) x (more y) = suc y -- Combining pattern matching and with: Agda-2.3.2.2/notes/review/0000755000000000000000000000000012221362553013332 5ustar0000000000000000Agda-2.3.2.2/notes/review/patrik/0000755000000000000000000000000012221362553014624 5ustar0000000000000000Agda-2.3.2.2/notes/review/patrik/log.txt0000644000000000000000000000152212221362553016146 0ustar0000000000000000051128: Trying to use pfe Had to change one use of (Just x <- rename x) in a guard. The result is quite as nice, but it is Haskell98. Next problem: deriving Data is accepted by pfe - sending an email to hallgren@cse.ogi.edu asking to pointers. 051117: PJ reading code (code review) Syntax.Explanation: I don't get this type (and it is hardly used) InCode: is only used in this module (in def. of getRange) ConcreteExpr: only used in getConcreteExpr - returns first Expr only ConcreteDecls: never used, and I don't understand it explain: never used, strange to allow empty list (breaks invariant) Explanation: what is a "derivation"? word never used elsewhere in the Agda2 code. Syntax.Abstract: What is Expl used for in most Expr? {- trying to get pfe going to use it to find uses -}Agda-2.3.2.2/notes/typechecking/0000755000000000000000000000000012221362553014506 5ustar0000000000000000Agda-2.3.2.2/notes/typechecking/algorithm.tex0000644000000000000000000003314012221362553017217 0ustar0000000000000000\documentclass[a4paper,11pt]{article} \usepackage[OT1]{fontenc} \usepackage[latin1]{inputenc} \usepackage{amsmath,amssymb,amsfonts} \usepackage{proof} \newcommand\keyword[1]{\mathbf{#1}} \newcommand\Coloneqq{\mathrel{::=}} \newcommand\OR{~~|~~} \newcommand\Hid[1]{\{#1\}} \newcommand\lam[1]{\lambda#1.\,} \newcommand\hlam[1]{\lam{\Hid{#1}}} \newcommand\tlam[2]{\lam{(#1:#2)}} \newcommand\thlam[2]{\lam{\Hid{#1:#2}}} \newcommand\ePi[3]{(#1:#2)\to#3} \newcommand\ehPi[3]{\{#1:#2\}\to#3} \newcommand\vPi[2]{\Pi#1:#2.\,} \newcommand\vhPi[2]{\Pi\{#1:#2\}.\,} \newcommand\vPiTel[1]{\Pi#1.\,} \newcommand\vhPiTel[1]{\vPiTel{\{#1\}}} \newcommand\Let[2]{\keyword{let}~#1~\keyword{in}~#2} \newcommand\Set[1]{\mathsf{Set}_{#1}} \newcommand\Prop{\mathsf{Prop}} \newcommand\el{\mathsf{El}} \newcommand\El[1]{\el_{#1}\,} \newcommand\lub{\sqcup} \newcommand\APP[2]{\mathsf{app}(#1,#2)} \newcommand\HAPP[2]{\mathsf{happ}(#1,#2)} \newcommand\Subst[3]{#1[#2/#3]} \newcommand\GetSort[1]{\mathsf{sortof}(#1)} % Judgement forms \renewcommand\Check[5]{#1\,;\,#2\vdash#3\uparrow#4:#5} \newcommand\Infer[5]{#1\,;\,#2\vdash#3\downarrow#4:#5} \newcommand\IsType[4]{#1\,;\,#2\vdash#3\uparrow#4~\mathbf{type}} \newcommand\Equal[5]{#1\,;\,#2\vdash#3=#4:#5} \newcommand\TEqual[4]{#1\,;\,#2\vdash#3=#4} \newcommand\Expand[6]{#1\,;\,#2\vdash#3:#4\prec#5:#6} \newcommand\CheckDecl[4]{#1\,;\,#2\vdash#3\to#4} \newcommand\AddGlobalMeta[4]{#1\,;\,#2\vdash{#3}:#4} \newcommand\AddLocalMeta[4]{#1\,;\,#2\vdash{#3}:#4} \title{Agda II Type Checking Algorithm} \author{Ulf Norell} \begin{document} \maketitle \section{Introduction} Write something nice here. \section{Syntax} \subsection{Expressions} Expressions have been scope checked, but not type checked. Hence the mix between terms, types and sorts. \[\begin{array}{lcl} e & \Coloneqq & x \OR c \OR l \OR ? \OR \_ \\ & \OR & \lam xe \OR \hlam xe \OR \tlam xee \OR \thlam xee \\ & \OR & e\,e \OR e\,\Hid e \OR \Let{\vec\delta}e \\ & \OR & \ePi xee \OR \ehPi xee \OR \Set n \OR \Prop \\ l & \Coloneqq & \mathit{integer} \OR \mathit{float} \OR \mathit{string} \OR \mathit{character} \\ \end{array}\] Constants ($c$) are names of constructors, defined functions, postulates and datatypes. \subsection{Declarations} \[\begin{array}{lcl} \delta & \Coloneqq & \ldots \end{array}\] \subsection{Terms} Terms are type checked versions of expressions (that aren't types). The type checking algorithm produces one of these when type checking. The implementation uses deBruijn variables, but to simplify the presentation we don't do that here. \[\begin{array}{lcl} s,t & \Coloneqq & x \OR c \OR l \OR ?_i \\ & \OR & \lam xt \OR \hlam xt \OR s\,t \OR s\,\Hid t \end{array}\] Worth noting is that meta variables are now named and that there are no typed lambdas left. Terms are supposed to always be on normal form. We do some work in the rules to ensure that this is the case. \subsection{Types and Sorts} After type checking we distinguish between terms, types and sorts. \[\begin{array}{lcl} A,B & \Coloneqq & \El\alpha t \OR \vPi xAB \OR \vhPi xAB \OR \alpha \\ \alpha,\beta & \Coloneqq & \Set n \OR \Prop \\ \end{array}\] In some presentation of the system design we had type and sort meta variables. I will try to do without them. What this means is that we can't, for instance, infer the type of a domain-free lambda by introducing a meta variable for the domain type. The reason for not having type meta variables is that I'm not sure how they interact with coercions. Depending on the order you solve constraints you might end up with different instantiations (since different coercions were applied). It might be that it doesn't matter, but until we're sure I prefer to err on the side of caution. If $x\notin\mathit{FV}(B)$ I will sometimes write $A\to B$ for $\vPi xAB$. \section{Judgement forms} In the judgement forms below $\Sigma$ is the signature and contains the type and definition (if any) of the constants currently in scope. $\Gamma$ is the context and contains the types of the bound variables. \[\begin{array}{ll} \Check\Sigma\Gamma etA & \mbox{Type checking, computes $t$.} \\ \Infer\Sigma\Gamma etA & \mbox{Type inference, computes $t$ and $A$.} \\ \IsType\Sigma\Gamma eA & \mbox{Checking that $e$ is a type, computes $A$.} \\ \Equal\Sigma\Gamma stA & \mbox{Typed conversion.} \\ % \TEqual\Sigma\Gamma AB & \mbox{Type conversion.} \\ \Expand\Sigma\Gamma sAtB & \mbox{Coercing conversion, computes $t$.} \\ \CheckDecl\Sigma\Gamma\delta{\Sigma'} & \mbox{Checking declarations, computes $\Sigma'$.} \end{array}\] The only non-standard judgement is the coercing conversion which replaces the convertibility judgement for types. The purpose of this judgement form is to insert things that have been hidden. For instance, suppose that $f:\vhPi A{\Set0}\vPi xAA$ in $\Sigma$ and we want to check $\Check\Sigma\Gamma ft{\vPi xBB}$. This should succeed with $t = f\,\Hid{B}$. The reason it does succeed is because we can coerce $f$ to have the desired type: \[ \Expand\Sigma\Gamma f{\vhPi A{\Set0}\vPi xAA}{f\,\Hid{B}}{\vPi xBB} \] \section{Judgements} \subsection{Checking} Type checking is used only as a last resort. If we can infer the type, that's what we do. \[\begin{array}{c} \infer{ \Check\Sigma\Gamma etB } { \Infer\Sigma\Gamma esA & \Expand\Sigma\Gamma sAtB } \end{array}\] The coercing conversion inserts any hidden lambdas or applications that are missing from $s$. We can't infer the type of domain free lambdas. \[\begin{array}{c} \infer{ \Check\Sigma\Gamma{\lam xe}{\lam xt}{\vPi xAB} } { \Check\Sigma{\Gamma,x:A}etB } \\{}\\ \infer{ \Check\Sigma\Gamma{\hlam xe}{\hlam xt}{\vhPi xAB} } { \Check\Sigma{\Gamma,x:A}etB } \end{array}\] If we're checking a non-hidden lambda against a hidden function type we should insert the appropriate number of hidden lambdas. There is some abuse of notation to make the rule more readable: If $\Delta = (x_1:A_1)\ldots(x_n:A_n)$, then $\hlam\Delta t$ means $\hlam{x_1}\ldots\hlam{x_n}t$ and $\vhPiTel\Delta B$ means $\vhPi{x_1}{A_1}\ldots\vhPi{x_n}{A_n}B$. \[\begin{array}{c} \infer{ \Check\Sigma\Gamma{\lam xe}{\hlam\Delta\lam xt}{\vhPiTel\Delta\vPi xAB} } { \Check\Sigma{\Gamma,\Delta,x:A} etB } \end{array}\] The type of meta variables can't be inferred either. \[\begin{array}{ccc} \infer[\AddGlobalMeta\Sigma\Gamma{?_i}A]{\Check\Sigma\Gamma{{?}}{{?_i}}A}{} && \infer[\AddLocalMeta\Sigma\Gamma{?_i}A]{\Check\Sigma\Gamma\_{{?_i}}A}{} \end{array}\] Let bindings can be inferred only if the body can be inferred, so we need a checking rule in case it can't. \[\begin{array}{c} \infer{ \Check\Sigma\Gamma{\Let\delta e}tA } { \CheckDecl\Sigma\Gamma\delta{\Sigma'} & \Check{\Sigma'}\Gamma etA } \end{array}\] An alternative approach would be to infer the type of everything, inserting meta variables when we don't know. This would require type and sort meta variables, though. \subsection{Inference} Inferring the type of a variable or a constant amounts to looking it up in the context or signature. This will never fail, since the expressions have been scope checked prior to type checking. \[\begin{array}{ccc} \infer{\Infer\Sigma\Gamma xx{\Gamma(x)}}{} && \infer{\Infer\Sigma\Gamma cc{\Sigma(x)}}{} \end{array}\] Literals have predefined types. \[\begin{array}{c} \infer{\Infer\Sigma\Gamma ll{\mathsf{typeof}(l)}}{} \end{array}\] There are three rules for application. The first two are for the easy cases where all implicit arguments have been made explicit. \[\begin{array}{c} \infer{ \Infer\Sigma\Gamma{e_1\,e_2}{\APP st}{\Subst Btx} } { \Infer\Sigma\Gamma{e_1}s{\vPi xAB} & \Check\Sigma\Gamma{e_2}tA } \\{}\\ \infer{ \Infer\Sigma\Gamma{e_1\,\Hid{e_2}}{\HAPP st}{\Subst Btx} } { \Infer\Sigma\Gamma{e_1}s{\vhPi xAB} & \Check\Sigma\Gamma{e_2}tA } \end{array}\] The functions $\APP --$ and $\HAPP --$ perform $\beta$-reductions and definition unfolding if necessary, to make sure that terms are on normal form. The third rule handles the case when you apply a function expecting hidden arguments to a non-hidden argument, in which case we have to fill in the hidden arguments with meta variables. \[\begin{array}{c} \infer[\AddLocalMeta\Sigma\Gamma{\vec ?}\Delta] { \Infer\Sigma\Gamma{e_1\,e_2}{\APP{\HAPP{s}{\vec{?}}}t}{B[\vec{?}/\Delta,t/x]} } { \Infer\Sigma\Gamma{e_1}s{\vhPiTel\Delta\vPi xAB} & \Check\Sigma\Gamma{e_2}t{\Subst A{\vec ?}\Delta} } \end{array}\] A consequence of these rules is that when you give a hidden argument explicitly it is always interpreted as the left-most hidden argument, so $f\,\Hid{x}\,y$ is the same as $f\,\Hid{x}\,\Hid{\_}\,y$ for an $f$ of the appropriate type. The inference rule for let is the same as the checking rule. \[\begin{array}{c} \infer{ \Infer\Sigma\Gamma{\Let\delta e}tA } { \CheckDecl\Sigma\Gamma\delta{\Sigma'} & \Infer{\Sigma'}\Gamma etA } \end{array}\] \subsection{Computing sorts} Types contain enough information to retrieve the sort. \[\begin{array}{lcl} \GetSort{\El\alpha t} & = & \alpha \\ \GetSort{\vPi xAB} & = & \GetSort A\lub\GetSort B \\ \GetSort{\vhPi xAB} & = & \GetSort A\lub\GetSort B \\ \GetSort{\Set n} & = & \Set{n+1} \\ \GetSort{\Prop} & = & \Set1 \\ {}\\ \Set n\lub\Set m & = & \Set{\mathsf{max}(n,m)} \\ \Prop\lub\Prop & = & \Prop \\ \Prop\lub\Set n & = & \Set1\lub\Set n \\ \Set n\lub\Prop & = & \Set n\lub\Set 1 \\ \end{array}\] In PTS terms we have the rule $(\alpha,\beta,\alpha\lub\beta)$. We might want to consider having $(\Set0,\Prop,\Prop)$ as well. \subsection{Is type} The {\em is type} judgement checks that an expression is a valid type and returns that type. It could also compute its sort but since we can easily get the sort of a type, it isn't necessary. \[\begin{array}{c} \infer { \IsType\Sigma\Gamma e{\El\alpha t} } { \Infer\Sigma\Gamma et\alpha } \end{array}\] \[\begin{array}{c} \infer { \IsType\Sigma\Gamma{\ePi x{e_1}{e_2}}{\vPi xAB} } { \IsType\Sigma\Gamma{e_1}A & \IsType\Sigma{\Gamma,x:A}{e_2}B } \\{}\\ \infer { \IsType\Sigma\Gamma{\ehPi x{e_1}{e_2}}{\vhPi xAB} } { \IsType\Sigma\Gamma{e_1}A & \IsType\Sigma{\Gamma,x:A}{e_2}B } \end{array}\] \[\begin{array}{c} \infer { \IsType\Sigma\Gamma\alpha{\GetSort\alpha} } {} \end{array}\] \subsection{Coercing conversion} The coercing conversion $\Expand\Sigma\Gamma sAtB$ computes a $t$ of type $B$ given an $s$ of type $A$, by adding hidden applications or lambdas to $s$ until the types $A$ and $B$ match. % In the following two rules $C$ should not be a hidden function space % ($\vhPi xAB$). \[\begin{array}{c} \infer[\AddLocalMeta\Sigma\Gamma{?_i}A] { \Expand\Sigma\Gamma s{\vhPi xAB}tC } { \Expand\Sigma\Gamma{\HAPP s{?_i}}{\Subst B{?_i}x}tC } \\{}\\ \infer { \Expand\Sigma\Gamma sC{\hlam xt}{\vhPi xAB} } { \Expand\Sigma{\Gamma,x:A}sCtB } \end{array}\] The first rule applies when $C$ is not a hidden function space, and the second rule is applicable for any $C$. This has the effect of $\eta$-expanding functions with hidden arguments. This allows, for instance, $s:\vhPiTel{A,B:\Set0}A\to B\to A$ to be coerced to $\hlam As\,\Hid A\,\Hid A : \vhPi A{\Set0}A\to A\to A$. If both types are normal function spaces we $\eta$-expand. \[\begin{array}{c} \infer { \Expand\Sigma\Gamma s{\vPi xAB}{\lam ys'}{\vPi y{A'}B'} } { \Expand\Sigma{\Gamma,y:A'}y{A'}tA & \Expand\Sigma{\Gamma,y:A'}{s\,t}{\Subst Btx}{s'}{B'} } \end{array}\] This allows us to perform coercions in higher order functions. For instance, \[ \Expand\Sigma\Gamma f{(B\to B)\to C} {\lam xf\,(x\,\Hid{B})} {(\vhPi A{\Set0}A\to A)\to C} \] The last two cases are when the types are $\el$s or sorts. In neither case are there any coercions. \[\begin{array}{ccc} \infer { \Expand\Sigma\Gamma t\alpha t\alpha } {} && \infer { \Expand\Sigma\Gamma s{\El\alpha t_1}s{\El\alpha t_2} } { \Equal\Sigma\Gamma{t_1}{t_2}\alpha } \end{array}\] \subsection{Conversion} The conversion checking is type directed. This gives us $\eta$-equality for functions in a nice way. It also makes it possible to introduce proof irrelevance with a rule like this: \[\left(\begin{array}{c} \infer { \Equal\Sigma\Gamma pqP } { \GetSort{P} = \Prop } \end{array}\right)\] We don't do that at this point though, but only make use of the types in the function case: \[\begin{array}{c} \infer { \Equal\Sigma\Gamma st{\vPi xAB} } { \Equal\Sigma{\Gamma,x:A}{\APP sx}{\APP tx}B } \\{}\\ \infer { \Equal\Sigma\Gamma st{\vhPi xAB} } { \Equal\Sigma{\Gamma,x:A}{\HAPP sx}{\HAPP tx}B } \end{array}\] There are a number of notation abuses in the following two rules. Firstly, $\Equal\Sigma\Gamma{\vec s}{\vec t}\Delta$ denotes the extension of the conversion judgement to sequences of terms. I am also a bit sloppy with the hiding: in $\vPiTel\Delta A$, $\Delta$ can contain both hidden and non-hidden things. Consequently when I say $x\,\vec s$ it includes hidden applications. \[\begin{array}{c} \infer { \Equal\Sigma\Gamma{x\,\vec s}{x\,\vec t}A } { x:\vPiTel\Delta A'\in\Gamma & \Equal\Sigma\Gamma{\vec s}{\vec t}\Delta } \\{}\\ \infer { \Equal\Sigma\Gamma{c\,\vec s}{c\,\vec t}A } { c:\vPiTel\Delta A'\in\Sigma & \Equal\Sigma\Gamma{\vec s}{\vec t}\Delta } \end{array}\] \subsection{Declarations} \end{document} Agda-2.3.2.2/notes/typechecking/proof.sty0000644000000000000000000002236312221362553016402 0ustar0000000000000000% proof.sty (Proof Figure Macros) % % version 3.0 (for both LaTeX 2.09 and LaTeX 2e) % Mar 6, 1997 % Copyright (C) 1990 -- 1997, Makoto Tatsuta (tatsuta@nii.ac.jp) % % This program is free software; you can redistribute it or modify % it under the terms of the GNU General Public License as published by % the Free Software Foundation; either versions 1, or (at your option) % any later version. % % This program is distributed in the hope that it will be useful % but WITHOUT ANY WARRANTY; without even the implied warranty of % MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the % GNU General Public License for more details. % % Usage: % In \documentstyle, specify an optional style `proof', say, % \documentstyle[proof]{article}. % % The following macros are available: % % In all the following macros, all the arguments such as % and are processed in math mode. % % \infer % draws an inference. % % Use & in to delimit upper formulae. % consists more than 0 formulae. % % \infer returns \hbox{ ... } or \vbox{ ... } and % sets \@LeftOffset and \@RightOffset globally. % % \infer[