doc-src/IsarRef/pure.tex
 author wenzelm Sat Oct 30 20:13:16 1999 +0200 (1999-10-30) changeset 7981 5120a2a15d06 parent 7974 34245feb6e82 child 7987 d9aef93c0e32 permissions -rw-r--r--
tuned;
     1

     2 \chapter{Basic Isar Language Elements}\label{ch:pure-syntax}

     3

     4 Subsequently, we introduce the main part of the basic Isar theory and proof

     5 commands as provided by Isabelle/Pure.  Chapter~\ref{ch:gen-tools} describes

     6 further Isar elements provided by generic tools and packages (such as the

     7 Simplifier) that are either part of Pure Isabelle or pre-loaded by most object

     8 logics.  Chapter~\ref{ch:hol-tools} refers to actual object-logic specific

     9 elements of Isabelle/HOL.

    10

    11 \medskip

    12

    13 Isar commands may be either \emph{proper} document constructors, or

    14 \emph{improper commands}.  Some proof methods and attributes introduced later

    15 are classified as improper as well.  Improper Isar language elements, which

    16 are subsequently marked by $^*$, are often helpful when developing proof

    17 documents, while their use is discouraged for the final outcome.  Typical

    18 examples are diagnostic commands that print terms or theorems according to the

    19 current context; other commands even emulate old-style tactical theorem

    20 proving, which facilitates porting of legacy proof scripts.

    21

    22

    23 \section{Theory commands}

    24

    25 \subsection{Defining theories}\label{sec:begin-thy}

    26

    27 \indexisarcmd{header}\indexisarcmd{theory}\indexisarcmd{end}\indexisarcmd{context}

    28 \begin{matharray}{rcl}

    29   \isarcmd{header} & : & \isarkeep{toplevel} \\

    30   \isarcmd{theory} & : & \isartrans{\cdot}{theory} \\

    31   \isarcmd{context}^* & : & \isartrans{\cdot}{theory} \\

    32   \isarcmd{end} & : & \isartrans{theory}{\cdot} \\

    33 \end{matharray}

    34

    35 Isabelle/Isar new-style'' theories are either defined via theory files or

    36 interactively.  Both theory-level specifications and proofs are handled

    37 uniformly --- occasionally definitional mechanisms even require some explicit

    38 proof as well.  In contrast, old-style'' Isabelle theories support batch

    39 processing only, with the proof scripts collected in separate ML files.

    40

    41 The first actual command of any theory has to be $\THEORY$, starting a new

    42 theory based on the merge of existing ones.  Just preceding $\THEORY$, there

    43 may be an optional $\isarkeyword{header}$ declaration, which is relevant to

    44 document preparation only; it acts very much like a special pre-theory markup

    45 command (cf.\ \S\ref{sec:markup-thy} and \S\ref{sec:markup-thy}).  The theory

    46 context may be also changed by $\CONTEXT$ without creating a new theory.  In

    47 both cases, $\END$ concludes the theory development; it has to be the very

    48 last command in a theory file.

    49

    50 \begin{rail}

    51   'header' text

    52   ;

    53   'theory' name '=' (name + '+') filespecs? ':'

    54   ;

    55   'context' name

    56   ;

    57   'end'

    58   ;;

    59

    60   filespecs: 'files' ((name | parname) +);

    61 \end{rail}

    62

    63 \begin{descr}

    64 \item [$\isarkeyword{header}~text$] provides plain text markup just preceding

    65   the formal begin of a theory.  In actual document preparation the

    66   corresponding {\LaTeX} macro \verb,\isamarkupheader, may be redefined to

    67   produce chapter or section headings.  See also \S\ref{sec:markup-thy} and

    68   \S\ref{sec:markup-prf} for further markup commands.

    69

    70 \item [$\THEORY~A = B@1 + \cdots + B@n\colon$] commences a new theory $A$

    71   based on existing ones $B@1 + \cdots + B@n$.  Isabelle's theory loader

    72   system ensures that any of the base theories are properly loaded (and fully

    73   up-to-date when $\THEORY$ is executed interactively).  The optional

    74   $\isarkeyword{files}$ specification declares additional dependencies on ML

    75   files.  Unless put in parentheses, any file will be loaded immediately via

    76   $\isarcmd{use}$ (see also \S\ref{sec:ML}).  The optional ML file

    77   \texttt{$A$.ML} that may be associated with any theory should \emph{not} be

    78   included in $\isarkeyword{files}$, though.

    79

    80 \item [$\CONTEXT~B$] enters an existing theory context, basically in read-only

    81   mode, so only a limited set of commands may be performed without destroying

    82   the theory.  Just as for $\THEORY$, the theory loader ensures that $B$ is

    83   loaded and up-to-date.

    84

    85 \item [$\END$] concludes the current theory definition or context switch.

    86 Note that this command cannot be undone, but the whole theory definition has

    87 to be retracted.

    88 \end{descr}

    89

    90

    91 \subsection{Theory markup commands}\label{sec:markup-thy}

    92

    93 \indexisarcmd{chapter}\indexisarcmd{section}\indexisarcmd{subsection}

    94 \indexisarcmd{subsubsection}\indexisarcmd{text}\indexisarcmd{text-raw}

    95 \begin{matharray}{rcl}

    96   \isarcmd{chapter} & : & \isartrans{theory}{theory} \\

    97   \isarcmd{section} & : & \isartrans{theory}{theory} \\

    98   \isarcmd{subsection} & : & \isartrans{theory}{theory} \\

    99   \isarcmd{subsubsection} & : & \isartrans{theory}{theory} \\

   100   \isarcmd{text} & : & \isartrans{theory}{theory} \\

   101   \isarcmd{text_raw} & : & \isartrans{theory}{theory} \\

   102 \end{matharray}

   103

   104 Apart from formal comments (see \S\ref{sec:comments}), markup commands provide

   105 a structured way to insert text into the document generated from a theory (see

   106 \cite{isabelle-sys} for more information on Isabelle's document preparation

   107 tools).

   108

   109 \railalias{textraw}{text\_raw}

   110 \railterm{textraw}

   111

   112 \begin{rail}

   113   ('chapter' | 'section' | 'subsection' | 'subsubsection' | 'text' | textraw) text

   114   ;

   115 \end{rail}

   116

   117 \begin{descr}

   118 \item [$\isarkeyword{chapter}$, $\isarkeyword{section}$,

   119   $\isarkeyword{subsection}$, and $\isarkeyword{subsubsection}$] mark chapter

   120   and section headings.

   121 \item [$\TEXT$] specifies paragraphs of plain text, including references to

   122   formal entities.\footnote{The latter feature is not yet supported.

   123     Nevertheless, any source text of the form

   124     \texttt{\at\ttlbrace$\dots$\ttrbrace}'' should be considered as reserved

   125     for future use.}

   126 \item [$\isarkeyword{text_raw}$] inserts {\LaTeX} source into the output,

   127   without additional markup.  Thus the full range of document manipulations

   128   becomes available.  A typical application would be to emit

   129   \verb,\begin{comment}, and \verb,\end{comment}, commands to exclude certain

   130   parts from the final document.\footnote{This requires the \texttt{comment}

   131     package to be included in {\LaTeX}.}

   132 \end{descr}

   133

   134 Any markup command (except $\isarkeyword{text_raw}$) corresponds to a {\LaTeX}

   135 macro with the name prefixed by \verb,\isamarkup, (e.g.\

   136 \verb,\isamarkupchapter, for $\isarkeyword{chapter}$). The \railqtoken{text}

   137 argument is passed to that macro unchanged, i.e.\ further {\LaTeX} commands

   138 may be included here as well.

   139

   140 \medskip Additional markup commands are available for proofs (see

   141 \S\ref{sec:markup-prf}).  Also note that the $\isarkeyword{header}$

   142 declaration (see \S\ref{sec:begin-thy}) admits to insert document markup

   143 elements just preceding the actual theory definition.

   144

   145

   146 \subsection{Type classes and sorts}\label{sec:classes}

   147

   148 \indexisarcmd{classes}\indexisarcmd{classrel}\indexisarcmd{defaultsort}

   149 \begin{matharray}{rcl}

   150   \isarcmd{classes} & : & \isartrans{theory}{theory} \\

   151   \isarcmd{classrel} & : & \isartrans{theory}{theory} \\

   152   \isarcmd{defaultsort} & : & \isartrans{theory}{theory} \\

   153 \end{matharray}

   154

   155 \begin{rail}

   156   'classes' (classdecl comment? +)

   157   ;

   158   'classrel' nameref '<' nameref comment?

   159   ;

   160   'defaultsort' sort comment?

   161   ;

   162 \end{rail}

   163

   164 \begin{descr}

   165 \item [$\isarkeyword{classes}~c<\vec c$] declares class $c$ to be a subclass

   166   of existing classes $\vec c$.  Cyclic class structures are ruled out.

   167 \item [$\isarkeyword{classrel}~c@1<c@2$] states a subclass relation between

   168   existing classes $c@1$ and $c@2$.  This is done axiomatically!  The

   169   $\isarkeyword{instance}$ command (see \S\ref{sec:axclass}) provides a way to

   170   introduce proven class relations.

   171 \item [$\isarkeyword{defaultsort}~s$] makes sort $s$ the new default sort for

   172   any type variables given without sort constraints.  Usually, the default

   173   sort would be only changed when defining new logics.

   174 \end{descr}

   175

   176

   177 \subsection{Primitive types and type abbreviations}\label{sec:types-pure}

   178

   179 \indexisarcmd{typedecl}\indexisarcmd{types}\indexisarcmd{nonterminals}\indexisarcmd{arities}

   180 \begin{matharray}{rcl}

   181   \isarcmd{types} & : & \isartrans{theory}{theory} \\

   182   \isarcmd{typedecl} & : & \isartrans{theory}{theory} \\

   183   \isarcmd{nonterminals} & : & \isartrans{theory}{theory} \\

   184   \isarcmd{arities} & : & \isartrans{theory}{theory} \\

   185 \end{matharray}

   186

   187 \begin{rail}

   188   'types' (typespec '=' type infix? comment? +)

   189   ;

   190   'typedecl' typespec infix? comment?

   191   ;

   192   'nonterminals' (name +) comment?

   193   ;

   194   'arities' (nameref '::' arity comment? +)

   195   ;

   196 \end{rail}

   197

   198 \begin{descr}

   199 \item [$\TYPES~(\vec\alpha)t = \tau$] introduces \emph{type synonym}

   200   $(\vec\alpha)t$ for existing type $\tau$.  Unlike actual type definitions,

   201   as are available in Isabelle/HOL for example, type synonyms are just purely

   202   syntactic abbreviations without any logical significance.  Internally, type

   203   synonyms are fully expanded.

   204 \item [$\isarkeyword{typedecl}~(\vec\alpha)t$] declares a new type constructor

   205   $t$, intended as an actual logical type.  Note that object-logics such as

   206   Isabelle/HOL override $\isarkeyword{typedecl}$ by their own version.

   207 \item [$\isarkeyword{nonterminals}~\vec c$] declares $0$-ary type constructors

   208   $\vec c$ to act as purely syntactic types, i.e.\ nonterminal symbols of

   209   Isabelle's inner syntax of terms or types.

   210 \item [$\isarkeyword{arities}~t::(\vec s)s$] augments Isabelle's order-sorted

   211   signature of types by new type constructor arities.  This is done

   212   axiomatically!  The $\isarkeyword{instance}$ command (see

   213   \S\ref{sec:axclass}) provides a way to introduce proven type arities.

   214 \end{descr}

   215

   216

   217 \subsection{Constants and simple definitions}\label{sec:consts}

   218

   219 \indexisarcmd{consts}\indexisarcmd{defs}\indexisarcmd{constdefs}\indexoutertoken{constdecl}

   220 \begin{matharray}{rcl}

   221   \isarcmd{consts} & : & \isartrans{theory}{theory} \\

   222   \isarcmd{defs} & : & \isartrans{theory}{theory} \\

   223   \isarcmd{constdefs} & : & \isartrans{theory}{theory} \\

   224 \end{matharray}

   225

   226 \begin{rail}

   227   'consts' (constdecl +)

   228   ;

   229   'defs' (axmdecl prop comment? +)

   230   ;

   231   'constdefs' (constdecl prop comment? +)

   232   ;

   233

   234   constdecl: name '::' type mixfix? comment?

   235   ;

   236 \end{rail}

   237

   238 \begin{descr}

   239 \item [$\CONSTS~c::\sigma$] declares constant $c$ to have any instance of type

   240   scheme $\sigma$.  The optional mixfix annotations may attach concrete syntax

   241   to the constants declared.

   242 \item [$\DEFS~name: eqn$] introduces $eqn$ as a definitional axiom for some

   243   existing constant.  See \cite[\S6]{isabelle-ref} for more details on the

   244   form of equations admitted as constant definitions.

   245 \item [$\isarkeyword{constdefs}~c::\sigma~eqn$] combines declarations and

   246   definitions of constants, using canonical name $c_def$ for the definitional

   247   axiom.

   248 \end{descr}

   249

   250

   251 \subsection{Syntax and translations}\label{sec:syn-trans}

   252

   253 \indexisarcmd{syntax}\indexisarcmd{translations}

   254 \begin{matharray}{rcl}

   255   \isarcmd{syntax} & : & \isartrans{theory}{theory} \\

   256   \isarcmd{translations} & : & \isartrans{theory}{theory} \\

   257 \end{matharray}

   258

   259 \begin{rail}

   260   'syntax' ('(' name 'output'? ')')? (constdecl +)

   261   ;

   262   'translations' (transpat ('==' | '=>' | '<=') transpat comment? +)

   263   ;

   264   transpat: ('(' nameref ')')? string

   265   ;

   266 \end{rail}

   267

   268 \begin{descr}

   269 \item [$\isarkeyword{syntax}~(mode)~decls$] is similar to $\CONSTS~decls$,

   270   except that the actual logical signature extension is omitted.  Thus the

   271   context free grammar of Isabelle's inner syntax may be augmented in

   272   arbitrary ways, independently of the logic.  The $mode$ argument refers to

   273   the print mode that the grammar rules belong; unless there is the

   274   \texttt{output} flag given, all productions are added both to the input and

   275   output grammar.

   276 \item [$\isarkeyword{translations}~rules$] specifies syntactic translation

   277   rules (i.e.\ \emph{macros}): parse~/ print rules (\texttt{==}), parse rules

   278   (\texttt{=>}), or print rules (\texttt{<=}).  Translation patterns may be

   279   prefixed by the syntactic category to be used for parsing; the default is

   280   \texttt{logic}.

   281 \end{descr}

   282

   283

   284 \subsection{Axioms and theorems}

   285

   286 \indexisarcmd{axioms}\indexisarcmd{theorems}\indexisarcmd{lemmas}

   287 \begin{matharray}{rcl}

   288   \isarcmd{axioms} & : & \isartrans{theory}{theory} \\

   289   \isarcmd{theorems} & : & \isartrans{theory}{theory} \\

   290   \isarcmd{lemmas} & : & \isartrans{theory}{theory} \\

   291 \end{matharray}

   292

   293 \begin{rail}

   294   'axioms' (axmdecl prop comment? +)

   295   ;

   296   ('theorems' | 'lemmas') thmdef? thmrefs

   297   ;

   298 \end{rail}

   299

   300 \begin{descr}

   301 \item [$\isarkeyword{axioms}~a: \phi$] introduces arbitrary statements as

   302   axioms of the meta-logic.  In fact, axioms are axiomatic theorems'', and

   303   may be referred later just as any other theorem.

   304

   305   Axioms are usually only introduced when declaring new logical systems.

   306   Everyday work is typically done the hard way, with proper definitions and

   307   actual theorems.

   308 \item [$\isarkeyword{theorems}~a = \vec b$] stores lists of existing theorems.

   309   Typical applications would also involve attributes, to augment the

   310   Simplifier context, for example.

   311 \item [$\isarkeyword{lemmas}$] is similar to $\isarkeyword{theorems}$, but

   312   tags the results as lemma''.

   313 \end{descr}

   314

   315

   316 \subsection{Name spaces}

   317

   318 \indexisarcmd{global}\indexisarcmd{local}

   319 \begin{matharray}{rcl}

   320   \isarcmd{global} & : & \isartrans{theory}{theory} \\

   321   \isarcmd{local} & : & \isartrans{theory}{theory} \\

   322 \end{matharray}

   323

   324 Isabelle organizes any kind of name declarations (of types, constants,

   325 theorems etc.)  by hierarchically structured name spaces.  Normally the user

   326 never has to control the behavior of name space entry by hand, yet the

   327 following commands provide some way to do so.

   328

   329 \begin{descr}

   330 \item [$\isarkeyword{global}$ and $\isarkeyword{local}$] change the current

   331   name declaration mode.  Initially, theories start in $\isarkeyword{local}$

   332   mode, causing all names to be automatically qualified by the theory name.

   333   Changing this to $\isarkeyword{global}$ causes all names to be declared

   334   without the theory prefix, until $\isarkeyword{local}$ is declared again.

   335 \end{descr}

   336

   337

   338 \subsection{Incorporating ML code}\label{sec:ML}

   339

   340 \indexisarcmd{use}\indexisarcmd{ML}\indexisarcmd{ML-setup}\indexisarcmd{setup}

   341 \begin{matharray}{rcl}

   342   \isarcmd{use} & : & \isartrans{\cdot}{\cdot} \\

   343   \isarcmd{ML} & : & \isartrans{\cdot}{\cdot} \\

   344   \isarcmd{ML_setup} & : & \isartrans{theory}{theory} \\

   345   \isarcmd{setup} & : & \isartrans{theory}{theory} \\

   346 \end{matharray}

   347

   348 \railalias{MLsetup}{ML\_setup}

   349 \railterm{MLsetup}

   350

   351 \begin{rail}

   352   'use' name

   353   ;

   354   ('ML' | MLsetup | 'setup') text

   355   ;

   356 \end{rail}

   357

   358 \begin{descr}

   359 \item [$\isarkeyword{use}~file$] reads and executes ML commands from $file$.

   360   The current theory context (if present) is passed down to the ML session,

   361   but may not be modified.  Furthermore, the file name is checked with the

   362   $\isarkeyword{files}$ dependency declaration given in the theory header (see

   363   also \S\ref{sec:begin-thy}).

   364

   365 \item [$\isarkeyword{ML}~text$] executes ML commands from $text$.  The theory

   366   context is passed in the same way as for $\isarkeyword{use}$.

   367

   368 \item [$\isarkeyword{ML_setup}~text$] executes ML commands from $text$.  The

   369   theory context is passed down to the ML session, and fetched back

   370   afterwards.  Thus $text$ may actually change the theory as a side effect.

   371

   372 \item [$\isarkeyword{setup}~text$] changes the current theory context by

   373   applying setup functions from $text$, which refers to an ML expression of

   374   type $(theory \to theory)~list$.  The $\isarkeyword{setup}$ command is the

   375   canonical way to initialize object-logic specific tools and packages written

   376   in ML.

   377 \end{descr}

   378

   379

   380 %FIXME remove!?

   381 %\subsection{Syntax translation functions}

   382

   383 %\indexisarcmd{parse-ast-translation}\indexisarcmd{parse-translation}

   384 %\indexisarcmd{print-translation}\indexisarcmd{typed-print-translation}

   385 %\indexisarcmd{print-ast-translation}\indexisarcmd{token-translation}

   386 %\begin{matharray}{rcl}

   387 %  \isarcmd{parse_ast_translation} & : & \isartrans{theory}{theory} \\

   388 %  \isarcmd{parse_translation} & : & \isartrans{theory}{theory} \\

   389 %  \isarcmd{print_translation} & : & \isartrans{theory}{theory} \\

   390 %  \isarcmd{typed_print_translation} & : & \isartrans{theory}{theory} \\

   391 %  \isarcmd{print_ast_translation} & : & \isartrans{theory}{theory} \\

   392 %  \isarcmd{token_translation} & : & \isartrans{theory}{theory} \\

   393 %\end{matharray}

   394

   395 %Syntax translation functions written in ML admit almost arbitrary

   396 %manipulations of Isabelle's inner syntax.  Any of the above commands have a

   397 %single \railqtoken{text} argument that refers to an ML expression of

   398 %appropriate type.  See \cite[\S8]{isabelle-ref} for more information on syntax

   399 %transformations.

   400

   401

   402 \subsection{Oracles}

   403

   404 \indexisarcmd{oracle}

   405 \begin{matharray}{rcl}

   406   \isarcmd{oracle} & : & \isartrans{theory}{theory} \\

   407 \end{matharray}

   408

   409 Oracles provide an interface to external reasoning systems, without giving up

   410 control completely --- each theorem carries a derivation object recording any

   411 oracle invocation.  See \cite[\S6]{isabelle-ref} for more information.

   412

   413 \begin{rail}

   414   'oracle' name '=' text comment?

   415   ;

   416 \end{rail}

   417

   418 \begin{descr}

   419 \item [$\isarkeyword{oracle}~name=text$] declares oracle $name$ to be ML

   420   function $text$, which has to be of type $Sign\mathord.sg \times   421 Object\mathord.T \to term$.

   422 \end{descr}

   423

   424

   425 \section{Proof commands}

   426

   427 Proof commands provide transitions of Isar/VM machine configurations, which

   428 are block-structured, consisting of a stack of nodes with three main

   429 components: logical proof context, current facts, and open goals.  Isar/VM

   430 transitions are \emph{typed} according to the following three three different

   431 modes of operation:

   432 \begin{descr}

   433 \item [$proof(prove)$] means that a new goal has just been stated that is now

   434   to be \emph{proven}; the next command may refine it by some proof method

   435   (read: tactic), and enter a sub-proof to establish the actual result.

   436 \item [$proof(state)$] is like an internal theory mode: the context may be

   437   augmented by \emph{stating} additional assumptions, intermediate result etc.

   438 \item [$proof(chain)$] is intermediate between $proof(state)$ and

   439   $proof(prove)$: existing facts (i.e.\ the contents of $this$) have been just

   440   picked up in order to be used when refining the goal claimed next.

   441 \end{descr}

   442

   443

   444 \subsection{Proof markup commands}\label{sec:markup-prf}

   445

   446 \indexisarcmd{sect}\indexisarcmd{subsect}\indexisarcmd{subsect}

   447 \indexisarcmd{txt}\indexisarcmd{txt-raw}

   448 \begin{matharray}{rcl}

   449   \isarcmd{sect} & : & \isartrans{proof(state)}{proof(state)} \\

   450   \isarcmd{subsect} & : & \isartrans{proof(state)}{proof(state)} \\

   451   \isarcmd{subsubsect} & : & \isartrans{proof(state)}{proof(state)} \\

   452   \isarcmd{txt} & : & \isartrans{proof(state)}{proof(state)} \\

   453   \isarcmd{txt_raw} & : & \isartrans{proof(state)}{proof(state)} \\

   454 \end{matharray}

   455

   456 These markup commands for proof mode closely correspond to the ones of theory

   457 mode (see \S\ref{sec:markup-thy}).  Note that $\isarkeyword{txt_raw}$ is

   458 special in the same way as $\isarkeyword{text_raw}$.

   459

   460 \railalias{txtraw}{txt\_raw}

   461 \railterm{txtraw}

   462

   463 \begin{rail}

   464   ('sect' | 'subsect' | 'subsubsect' | 'txt' | txtraw) text

   465   ;

   466 \end{rail}

   467

   468

   469 \subsection{Proof context}\label{sec:proof-context}

   470

   471 \indexisarcmd{fix}\indexisarcmd{assume}\indexisarcmd{presume}\indexisarcmd{def}

   472 \begin{matharray}{rcl}

   473   \isarcmd{fix} & : & \isartrans{proof(state)}{proof(state)} \\

   474   \isarcmd{assume} & : & \isartrans{proof(state)}{proof(state)} \\

   475   \isarcmd{presume} & : & \isartrans{proof(state)}{proof(state)} \\

   476   \isarcmd{def} & : & \isartrans{proof(state)}{proof(state)} \\

   477 \end{matharray}

   478

   479 The logical proof context consists of fixed variables and assumptions.  The

   480 former closely correspond to Skolem constants, or meta-level universal

   481 quantification as provided by the Isabelle/Pure logical framework.

   482 Introducing some \emph{arbitrary, but fixed} variable via $\FIX x$ results in

   483 a local object that may be used in the subsequent proof as any other variable

   484 or constant.  Furthermore, any result $\edrv \phi[x]$ exported from the

   485 current context will be universally closed wrt.\ $x$ at the outermost level:

   486 $\edrv \All x \phi$; this is expressed using Isabelle's meta-variables.

   487

   488 Similarly, introducing some assumption $\chi$ has two effects.  On the one

   489 hand, a local theorem is created that may be used as a fact in subsequent

   490 proof steps.  On the other hand, any result $\chi \drv \phi$ exported from the

   491 context becomes conditional wrt.\ the assumption: $\edrv \chi \Imp \phi$.

   492 Thus, solving an enclosing goal using such a result would basically introduce

   493 a new subgoal stemming from the assumption.  How this situation is handled

   494 depends on the actual version of assumption command used: while $\ASSUMENAME$

   495 insists on solving the subgoal by unification with some premise of the goal,

   496 $\PRESUMENAME$ leaves the subgoal unchanged in order to be proved later by the

   497 user.

   498

   499 Local definitions, introduced by $\DEF{}{x \equiv t}$, are achieved by

   500 combining $\FIX x$ with another kind of assumption that causes any

   501 hypothetical equation $x \equiv t$ to be eliminated by reflexivity.  Thus,

   502 exporting some result $x \equiv t \drv \phi[x]$ yields $\edrv \phi[t]$.

   503

   504 \begin{rail}

   505   'fix' (vars + 'and') comment?

   506   ;

   507   ('assume' | 'presume') (assm comment? + 'and')

   508   ;

   509   'def' thmdecl? \\ var '==' term termpat? comment?

   510   ;

   511

   512   var: name ('::' type)?

   513   ;

   514   vars: (name+) ('::' type)?

   515   ;

   516   assm: thmdecl? (prop proppat? +)

   517   ;

   518 \end{rail}

   519

   520 \begin{descr}

   521 \item [$\FIX{x}$] introduces a local \emph{arbitrary, but fixed} variable $x$.

   522 \item [$\ASSUME{a}{\Phi}$ and $\PRESUME{a}{\Phi}$] introduce local theorems

   523   $\Phi$ by assumption.  Subsequent results applied to an enclosing goal

   524   (e.g.\ by $\SHOWNAME$) are handled as follows: $\ASSUMENAME$ expects to be

   525   able to unify with existing premises in the goal, while $\PRESUMENAME$

   526   leaves $\Phi$ as new subgoals.

   527

   528   Several lists of assumptions may be given (separated by

   529   $\isarkeyword{and}$); the resulting list of current facts consists of all of

   530   these concatenated.

   531 \item [$\DEF{a}{x \equiv t}$] introduces a local (non-polymorphic) definition.

   532   In results exported from the context, $x$ is replaced by $t$.  Basically,

   533   $\DEF{}{x \equiv t}$ abbreviates $\FIX{x}~\PRESUME{}{x \equiv t}$, with the

   534   resulting hypothetical equation solved by reflexivity.

   535

   536   The default name for the definitional equation is $x_def$.

   537 \end{descr}

   538

   539 The special name $prems$\indexisarthm{prems} refers to all assumptions of the

   540 current context as a list of theorems.

   541

   542

   543 \subsection{Facts and forward chaining}

   544

   545 \indexisarcmd{note}\indexisarcmd{then}\indexisarcmd{from}\indexisarcmd{with}

   546 \begin{matharray}{rcl}

   547   \isarcmd{note} & : & \isartrans{proof(state)}{proof(state)} \\

   548   \isarcmd{then} & : & \isartrans{proof(state)}{proof(chain)} \\

   549   \isarcmd{from} & : & \isartrans{proof(state)}{proof(chain)} \\

   550   \isarcmd{with} & : & \isartrans{proof(state)}{proof(chain)} \\

   551 \end{matharray}

   552

   553 New facts are established either by assumption or proof of local statements.

   554 Any fact will usually be involved in further proofs, either as explicit

   555 arguments of proof methods or when forward chaining towards the next goal via

   556 $\THEN$ (and variants).  Note that the special theorem name

   557 $this$.\indexisarthm{this} refers to the most recently established facts.

   558 \begin{rail}

   559   'note' thmdef? thmrefs comment?

   560   ;

   561   'then' comment?

   562   ;

   563   ('from' | 'with') thmrefs comment?

   564   ;

   565 \end{rail}

   566

   567 \begin{descr}

   568 \item [$\NOTE{a}{\vec b}$] recalls existing facts $\vec b$, binding the result

   569   as $a$.  Note that attributes may be involved as well, both on the left and

   570   right hand sides.

   571 \item [$\THEN$] indicates forward chaining by the current facts in order to

   572   establish the goal to be claimed next.  The initial proof method invoked to

   573   refine that will be offered the facts to do anything appropriate'' (cf.\

   574   also \S\ref{sec:proof-steps}).  For example, method $rule$ (see

   575   \S\ref{sec:pure-meth}) would typically do an elimination rather than an

   576   introduction.  Automatic methods usually insert the facts into the goal

   577   state before operation.

   578 \item [$\FROM{\vec b}$] abbreviates $\NOTE{}{\vec b}~\THEN$; thus $\THEN$ is

   579   equivalent to $\FROM{this}$.

   580 \item [$\WITH{\vec b}$] abbreviates $\FROM{\vec b~facts}$; thus the forward

   581   chaining is from earlier facts together with the current ones.

   582 \end{descr}

   583

   584 Basic proof methods (such as $rule$, see \S\ref{sec:pure-meth}) expect

   585 multiple facts to be given in their proper order, corresponding to a prefix of

   586 the premises of the rule involved.  Note that positions may be easily skipped

   587 using a form like $\FROM{\text{\texttt{_}}~a~b}$, for example.  This involves

   588 the trivial rule $\PROP\psi \Imp \PROP\psi$, which is bound in Isabelle/Pure

   589 as \texttt{_}'' (underscore).\indexisarthm{_@\texttt{_}}

   590

   591

   592 \subsection{Goal statements}

   593

   594 \indexisarcmd{theorem}\indexisarcmd{lemma}

   595 \indexisarcmd{have}\indexisarcmd{show}\indexisarcmd{hence}\indexisarcmd{thus}

   596 \begin{matharray}{rcl}

   597   \isarcmd{theorem} & : & \isartrans{theory}{proof(prove)} \\

   598   \isarcmd{lemma} & : & \isartrans{theory}{proof(prove)} \\

   599   \isarcmd{have} & : & \isartrans{proof(state)}{proof(prove)} \\

   600   \isarcmd{show} & : & \isartrans{proof(state)}{proof(prove)} \\

   601   \isarcmd{hence} & : & \isartrans{proof(state)}{proof(prove)} \\

   602   \isarcmd{thus} & : & \isartrans{proof(state)}{proof(prove)} \\

   603 \end{matharray}

   604

   605 Proof mode is entered from theory mode by initial goal commands $\THEOREMNAME$

   606 and $\LEMMANAME$.  New local goals may be claimed within proof mode as well.

   607 Four variants are available, indicating whether the result is meant to solve

   608 some pending goal and whether forward chaining is employed.

   609

   610 \begin{rail}

   611   ('theorem' | 'lemma') goal

   612   ;

   613   ('have' | 'show' | 'hence' | 'thus') goal

   614   ;

   615

   616   goal: thmdecl? proppat comment?

   617   ;

   618 \end{rail}

   619

   620 \begin{descr}

   621 \item [$\THEOREM{a}{\phi}$] enters proof mode with $\phi$ as main goal,

   622   eventually resulting in some theorem $\turn \phi$ put back into the theory.

   623 \item [$\LEMMANAME$] is similar to $\THEOREMNAME$, but tags the result as

   624   lemma''.

   625 \item [$\HAVE{a}{\phi}$] claims a local goal, eventually resulting in a

   626   theorem with the current assumption context as hypotheses.

   627 \item [$\SHOW{a}{\phi}$] is similar to $\HAVE{a}{\phi}$, but solves some

   628   pending goal with the result \emph{exported} into the corresponding context

   629   (cf.\ \S\ref{sec:proof-context}).

   630 \item [$\HENCENAME$] abbreviates $\THEN~\HAVENAME$, i.e.\ claims a local goal

   631   to be proven by forward chaining the current facts.  Note that $\HENCENAME$

   632   is also equivalent to $\FROM{this}~\HAVENAME$.

   633 \item [$\THUSNAME$] abbreviates $\THEN~\SHOWNAME$.  Note that $\THUSNAME$ is

   634   also equivalent to $\FROM{this}~\SHOWNAME$.

   635 \end{descr}

   636

   637

   638 \subsection{Initial and terminal proof steps}\label{sec:proof-steps}

   639

   640 \indexisarcmd{proof}\indexisarcmd{qed}\indexisarcmd{by}

   641 \indexisarcmd{.}\indexisarcmd{..}\indexisarcmd{sorry}

   642 \begin{matharray}{rcl}

   643   \isarcmd{proof} & : & \isartrans{proof(prove)}{proof(state)} \\

   644   \isarcmd{qed} & : & \isartrans{proof(state)}{proof(state) ~|~ theory} \\

   645   \isarcmd{by} & : & \isartrans{proof(prove)}{proof(state) ~|~ theory} \\

   646   \isarcmd{.\,.} & : & \isartrans{proof(prove)}{proof(state) ~|~ theory} \\

   647   \isarcmd{.} & : & \isartrans{proof(prove)}{proof(state) ~|~ theory} \\

   648   \isarcmd{sorry} & : & \isartrans{proof(prove)}{proof(state) ~|~ theory} \\

   649 \end{matharray}

   650

   651 Arbitrary goal refinement via tactics is considered harmful.  Consequently the

   652 Isar framework admits proof methods to be invoked in two places only.

   653 \begin{enumerate}

   654 \item An \emph{initial} refinement step $\PROOF{m@1}$ reduces a newly stated

   655   goal to a number of sub-goals that are to be solved later.  Facts are passed

   656   to $m@1$ for forward chaining, if so indicated by $proof(chain)$ mode.

   657

   658 \item A \emph{terminal} conclusion step $\QED{m@2}$ solves any remaining goals

   659   completely.  No facts are passed to $m@2$.

   660 \end{enumerate}

   661

   662 The only other proper way to affect pending goals is by $\SHOWNAME$ (or

   663 $\THUSNAME$), which involves an explicit statement of what is to be solved.

   664

   665 \medskip

   666

   667 Also note that initial proof methods should either solve the goal completely,

   668 or constitute some well-understood reduction to new sub-goals.  Arbitrary

   669 automatic proof tools that are prone leave a large number of badly structured

   670 sub-goals are no help in continuing the proof document in any intelligible

   671 way.  A much better technique would be to $\SHOWNAME$ some non-trivial

   672 reduction as an explicit rule, which is solved completely by some automated

   673 method, and then applied to some pending goal.

   674

   675 \medskip

   676

   677 Unless given explicitly by the user, the default initial method is

   678 $default$'', which is usually set up to apply a single standard elimination

   679 or introduction rule according to the topmost symbol involved.  There is no

   680 separate default terminal method; in any case the final step is to solve all

   681 remaining goals by assumption, though.

   682

   683 \begin{rail}

   684   'proof' interest? meth? comment?

   685   ;

   686   'qed' meth? comment?

   687   ;

   688   'by' meth meth? comment?

   689   ;

   690   ('.' | '..' | 'sorry') comment?

   691   ;

   692

   693   meth: method interest?

   694   ;

   695 \end{rail}

   696

   697 \begin{descr}

   698 \item [$\PROOF{m@1}$] refines the goal by proof method $m@1$; facts for

   699   forward chaining are passed if so indicated by $proof(chain)$ mode.

   700 \item [$\QED{m@2}$] refines any remaining goals by proof method $m@2$ and

   701   concludes the sub-proof by assumption.  If the goal had been $\SHOWNAME$ (or

   702   $\THUSNAME$), some pending sub-goal is solved as well by the rule resulting

   703   from the result \emph{exported} into the enclosing goal context.  Thus

   704   $\QEDNAME$ may fail for two reasons: either $m@2$ fails, or the resulting

   705   rule does not fit to any pending goal\footnote{This includes any additional

   706     strong'' assumptions as introduced by $\ASSUMENAME$.} of the enclosing

   707   context.  Debugging such a situation might involve temporarily changing

   708   $\SHOWNAME$ into $\HAVENAME$, or weakening the local context by replacing

   709   some occurrences of $\ASSUMENAME$ by $\PRESUMENAME$.

   710 \item [$\BYY{m@1}{m@2}$] is a \emph{terminal proof}\index{proof!terminal}; it

   711   abbreviates $\PROOF{m@1}~\QED{m@2}$, with automatic backtracking across both

   712   methods.  Debugging an unsuccessful $\BYY{m@1}{m@2}$ commands might be done

   713   by expanding its definition; in many cases $\PROOF{m@1}$ is already

   714   sufficient to see what is going wrong.

   715 \item [$\DDOT$''] is a \emph{default proof}\index{proof!default}; it

   716   abbreviates $\BY{default}$.

   717 \item [$\DOT$''] is a \emph{trivial proof}\index{proof!trivial}; it

   718   abbreviates $\BY{assumption}$.

   719 \item [$\isarkeyword{sorry}$] is a \emph{fake proof}\index{proof!fake};

   720   provided that \texttt{quick_and_dirty} is enabled, $\isarkeyword{sorry}$

   721   pretends to solve the goal without further ado.  Of course, the result is a

   722   fake theorem only, involving some oracle in its internal derivation object

   723   (this is indicated as $[!]$'' in the printed result).  The main

   724   application of $\isarkeyword{sorry}$ is to support experimentation and

   725   top-down proof development.

   726 \end{descr}

   727

   728

   729 \subsection{Improper proof steps}

   730

   731 The following commands emulate unstructured tactic scripts to some extent.

   732 While these are anathema for writing proper Isar proof documents, they might

   733 come in handy for interactive exploration and debugging.

   734

   735 \indexisarcmd{apply}\indexisarcmd{then-apply}\indexisarcmd{back}

   736 \begin{matharray}{rcl}

   737   \isarcmd{apply}^* & : & \isartrans{proof}{proof} \\

   738   \isarcmd{then_apply}^* & : & \isartrans{proof}{proof} \\

   739   \isarcmd{back}^* & : & \isartrans{proof}{proof} \\

   740 \end{matharray}

   741

   742 \railalias{thenapply}{then\_apply}

   743 \railterm{thenapply}

   744

   745 \begin{rail}

   746   'apply' method

   747   ;

   748   thenapply method

   749   ;

   750   'back'

   751   ;

   752 \end{rail}

   753

   754 \begin{descr}

   755 \item [$\isarkeyword{apply}~(m)$] applies proof method $m$ in the plain old

   756   tactic sense.  Facts for forward chaining are reset.

   757 \item [$\isarkeyword{then_apply}~(m)$] is similar to $\isarkeyword{apply}$,

   758   but keeps the goal's facts.

   759 \item [$\isarkeyword{back}$] does back-tracking over the result sequence of

   760   the latest proof command.\footnote{Unlike the ML function \texttt{back}

   761     \cite{isabelle-ref}, the Isar command does not search upwards for further

   762     branch points.} Basically, any proof command may return multiple results.

   763 \end{descr}

   764

   765

   766 \subsection{Term abbreviations}\label{sec:term-abbrev}

   767

   768 \indexisarcmd{let}

   769 \begin{matharray}{rcl}

   770   \isarcmd{let} & : & \isartrans{proof(state)}{proof(state)} \\

   771   \isarkeyword{is} & : & syntax \\

   772 \end{matharray}

   773

   774 Abbreviations may be either bound by explicit $\LET{p \equiv t}$ statements,

   775 or by annotating assumptions or goal statements ($\ASSUMENAME$, $\SHOWNAME$

   776 etc.) with a list of patterns $\ISS{p@1 \dots}{p@n}$.  In both cases,

   777 higher-order matching is invoked to bind extra-logical term variables, which

   778 may be either named schematic variables of the form $\Var{x}$, or nameless

   779 dummies \texttt{_}'' (underscore).\indexisarvar{_@\texttt{_}} Note that in

   780 the $\LETNAME$ form the patterns occur on the left-hand side, while the

   781 $\ISNAME$ patterns are in postfix position.

   782

   783 Term abbreviations are quite different from actual local definitions as

   784 introduced via $\DEFNAME$ (see \S\ref{sec:proof-context}).  The latter are

   785 visible within the logic as actual equations, while abbreviations disappear

   786 during the input process just after type checking.

   787

   788 \begin{rail}

   789   'let' ((term + 'as') '=' term comment? + 'and')

   790   ;

   791 \end{rail}

   792

   793 The syntax of $\ISNAME$ patterns follows \railnonterm{termpat} or

   794 \railnonterm{proppat} (see \S\ref{sec:term-pats}).

   795

   796 \begin{descr}

   797 \item [$\LET{\vec p = \vec t}$] binds any text variables in patters $\vec p$

   798   by simultaneous higher-order matching against terms $\vec t$.

   799 \item [$\IS{\vec p}$] resembles $\LETNAME$, but matches $\vec p$ against the

   800   preceding statement.  Also note that $\ISNAME$ is not a separate command,

   801   but part of others (such as $\ASSUMENAME$, $\HAVENAME$ etc.).

   802 \end{descr}

   803

   804 A few \emph{automatic} term abbreviations\index{automatic abbreviation} for

   805 goals and facts are available as well.  For any open goal,

   806 $\Var{thesis_prop}$\indexisarvar{thesis-prop} refers to the full proposition

   807 (which may be a rule), $\Var{thesis_concl}$\indexisarvar{thesis-concl} to its

   808 (atomic) conclusion, and $\Var{thesis}$\indexisarvar{thesis} to its

   809 object-logical statement.  The latter two abstract over any meta-level

   810 parameters bound by $\Forall$.

   811

   812 Fact statements resulting from assumptions or finished goals are bound as

   813 $\Var{this_prop}$\indexisarvar{this-prop},

   814 $\Var{this_concl}$\indexisarvar{this-concl}, and

   815 $\Var{this}$\indexisarvar{this}, similar to $\Var{thesis}$ above.  In case

   816 $\Var{this}$ refers to an object-logic statement that is an application

   817 $f(t)$, then $t$ is bound to the special text variable

   818 $\dots$''\indexisarvar{\dots} (three dots).  The canonical application of

   819 this feature are calculational proofs (see \S\ref{sec:calculation}).

   820

   821

   822 \subsection{Block structure}

   823

   824 \indexisarcmd{next}\indexisarcmd{\{\{}\indexisarcmd{\}\}}

   825 \begin{matharray}{rcl}

   826   \isarcmd{next} & : & \isartrans{proof(state)}{proof(state)} \\

   827   \BG & : & \isartrans{proof(state)}{proof(state)} \\

   828   \EN & : & \isartrans{proof(state)}{proof(state)} \\

   829 \end{matharray}

   830

   831 While Isar is inherently block-structured, opening and closing blocks is

   832 mostly handled rather casually, with little explicit user-intervention.  Any

   833 local goal statement automatically opens \emph{two} blocks, which are closed

   834 again when concluding the sub-proof (by $\QEDNAME$ etc.).  Sections of

   835 different context within a sub-proof may be switched via $\isarkeyword{next}$,

   836 which is just a single block-close followed by block-open again.  Thus the

   837 effect of $\isarkeyword{next}$ is a local reset the proof

   838 context.\footnote{There is no goal focus involved here!}

   839

   840 For slightly more advanced applications, there are explicit block parentheses

   841 as well.  These typically achieve a stronger forward style of reasoning.

   842

   843 \begin{descr}

   844 \item [$\isarkeyword{next}$] switches to a fresh block within a sub-proof,

   845   resetting the local context to the initial one.

   846 \item [$\isarkeyword{\{\{}$ and $\isarkeyword{\}\}}$] explicitly open and

   847   close blocks.  Any current facts pass through $\isarkeyword{\{\{}$''

   848   unchanged, while $\isarkeyword{\}\}}$'' causes any result to be

   849   \emph{exported} into the enclosing context.  Thus fixed variables are

   850   generalized, assumptions discharged, and local definitions unfolded (cf.\

   851   \S\ref{sec:proof-context}).  There is no difference of $\ASSUMENAME$ and

   852   $\PRESUMENAME$ in this mode of forward reasoning --- in contrast to plain

   853   backward reasoning with the result exported at $\SHOWNAME$ time.

   854 \end{descr}

   855

   856

   857 \section{Other commands}

   858

   859 \subsection{Diagnostics}

   860

   861 \indexisarcmd{thm}\indexisarcmd{term}\indexisarcmd{prop}\indexisarcmd{typ}

   862 \begin{matharray}{rcl}

   863   \isarcmd{thm} & : & \isarkeep{theory~|~proof} \\

   864   \isarcmd{term} & : & \isarkeep{theory~|~proof} \\

   865   \isarcmd{prop} & : & \isarkeep{theory~|~proof} \\

   866   \isarcmd{typ} & : & \isarkeep{theory~|~proof} \\

   867 \end{matharray}

   868

   869 These commands are not part of the actual Isabelle/Isar syntax, but assist

   870 interactive development.  Also note that $undo$ does not apply here, since the

   871 theory or proof configuration is not changed.

   872

   873 \begin{rail}

   874   'thm' thmrefs

   875   ;

   876   'term' term

   877   ;

   878   'prop' prop

   879   ;

   880   'typ' type

   881   ;

   882 \end{rail}

   883

   884 \begin{descr}

   885 \item [$\isarkeyword{thm}~thms$] retrieves lists of theorems from the current

   886   theory or proof context.  Note that any attributes included in the theorem

   887   specifications are applied to a temporary context derived from the current

   888   theory or proof; the result is discarded, i.e.\ attributes involved in

   889   $thms$ do not have any permanent effect.

   890 \item [$\isarkeyword{term}~t$, $\isarkeyword{prop}~\phi$] read, type-checks

   891   and print terms or propositions according to the current theory or proof

   892   context; the inferred type of $t$ is output as well.  Note that these

   893   commands are also useful in inspecting the current environment of term

   894   abbreviations.

   895 \item [$\isarkeyword{typ}~\tau$] reads and prints types of the meta-logic

   896   according to the current theory or proof context.

   897 \end{descr}

   898

   899

   900 \subsection{System operations}

   901

   902 \indexisarcmd{cd}\indexisarcmd{pwd}\indexisarcmd{use-thy}\indexisarcmd{use-thy-only}

   903 \indexisarcmd{update-thy}\indexisarcmd{update-thy-only}

   904 \begin{matharray}{rcl}

   905   \isarcmd{cd} & : & \isarkeep{\cdot} \\

   906   \isarcmd{pwd} & : & \isarkeep{\cdot} \\

   907   \isarcmd{use_thy} & : & \isarkeep{\cdot} \\

   908   \isarcmd{use_thy_only} & : & \isarkeep{\cdot} \\

   909   \isarcmd{update_thy} & : & \isarkeep{\cdot} \\

   910   \isarcmd{update_thy_only} & : & \isarkeep{\cdot} \\

   911 \end{matharray}

   912

   913 \begin{descr}

   914 \item [$\isarkeyword{cd}~name$] changes the current directory of the Isabelle

   915   process.

   916 \item [$\isarkeyword{pwd}~$] prints the current working directory.

   917 \item [$\isarkeyword{use_thy}$, $\isarkeyword{use_thy_only}$,

   918   $\isarkeyword{update_thy}$, and $\isarkeyword{update_thy_only}$] load some

   919   theory given as $name$ argument.  These commands are basically the same as

   920   the corresponding ML functions\footnote{For historic reasons, the original

   921     ML versions also change the theory context to that of the theory loaded.}

   922   (see also \cite[\S1,\S6]{isabelle-ref}).  Note that both the ML and Isar

   923   versions may load new- and old-style theories alike.

   924 \end{descr}

   925

   926 Note that these system commands are scarcely used when working with the

   927 Proof~General interface, since loading of theories is done fully

   928 transparently.

   929

   930 %%% Local Variables:

   931 %%% mode: latex

   932 %%% TeX-master: "isar-ref"

   933 %%% End: