Chapter 9 The tactic language
This chapter gives a compact documentation of Ltac, the tactic language available in Coq. We start by giving the syntax, and next, we present the informal semantics. If you want to know more regarding this language and especially about its foundations, you can refer to [41]. Chapter 10 is devoted to giving examples of use of this language on small but also with nontrivial problems.
9.1 Syntax
The syntax of the tactic language is given Figures 9.1 and 9.2. See Chapter 1 for a description of the BNF metasyntax used in these grammar rules. Various already defined entries will be used in this chapter: entries natural, integer, ident, qualid, term, cpattern and atomic_tactic represent respectively the natural and integer numbers, the authorized identificators and qualified names, Coq’s terms and patterns and all the atomic tactics described in Chapter 8. The syntax of cpattern is the same as that of terms, but it is extended with pattern matching metavariables. In cpattern, a patternmatching metavariable is represented with the syntax ?id where id is an ident. The notation _ can also be used to denote metavariable whose instance is irrelevant. In the notation ?id, the identifier allows us to keep instantiations and to make constraints whereas _ shows that we are not interested in what will be matched. On the right hand side of patternmatching clauses, the named metavariable are used without the question mark prefix. There is also a special notation for secondorder patternmatching problems: in an applicative pattern of the form @?id id_{1} …id_{n}, the variable id matches any complex expression with (possible) dependencies in the variables id_{1} …id_{n} and returns a functional term of the form fun id_{1} …id_{n} => term.
The main entry of the grammar is expr. This language is used in proof mode but it can also be used in toplevel definitions as shown in Figure 9.3.
Remarks:
 The infix tacticals “…  …” and “… ; …” are associative.
 In tacarg, there is an overlap between qualid as a direct tactic argument and qualid as a particular case of term. The resolution is done by first looking for a reference of the tactic language and if it fails, for a reference to a term. To force the resolution as a reference of the tactic language, use the form ltac : qualid. To force the resolution as a reference to a term, use the syntax (qualid).
 As shown by the figure, tactical  binds more than the
prefix tacticals try, repeat, do, info and
abstract which themselves bind more than the postfix tactical
“… ;[ … ]” which binds more than “… ;
…”.
For instance
try repeat tactic_{1}  tactic_{2};tactic_{3};[tactic_{31}…tactic_{3n}];tactic_{4}.
is understood as
(try (repeat (tactic_{1}  tactic_{2})));
((tactic_{3};[tactic_{31}…tactic_{3n}]);tactic_{4}).
expr ::= expr ; expr  expr ; [ expr  …  expr ]  tacexpr_{3} tacexpr_{3} ::= do (natural  ident) tacexpr_{3}  info tacexpr_{3}  progress tacexpr_{3}  repeat tacexpr_{3}  try tacexpr_{3}  tacexpr_{2} tacexpr_{2} ::= tacexpr_{1}  tacexpr_{3}  tacexpr_{1} tacexpr_{1} ::= fun name … name => atom  let [rec] let_clause with … with let_clause in atom  match goal with context_rule  …  context_rule end  match reverse goal with context_rule  …  context_rule end  match expr with match_rule  …  match_rule end  lazymatch goal with context_rule  …  context_rule end  lazymatch reverse goal with context_rule  …  context_rule end  lazymatch expr with match_rule  …  match_rule end  abstract atom  abstract atom using ident  first [ expr  …  expr ]  solve [ expr  …  expr ]  idtac [message_token … message_token]  fail [natural] [message_token … message_token]  fresh  fresh string  context ident [ term ]  eval redexpr in term  type of term  external string string tacarg … tacarg  constr : term  atomic_tactic  qualid tacarg … tacarg  atom atom ::= qualid  ()  integer  ( expr ) message_token ::= string  ident  integer
tacarg ::= qualid  ()  ltac : atom  term let_clause ::= ident [name … name] := expr context_rule ::= context_hyp , … , context_hyp cpattern => expr   cpattern => expr  _ => expr context_hyp ::= name : cpattern  name := cpattern [: cpattern] match_rule ::= cpattern => expr  context [ident] [ cpattern ] => expr  appcontext [ident] [ cpattern ] => expr  _ => expr
top ::= [Local] Ltac ltac_def with … with ltac_def ltac_def ::= ident [ident … ident] := expr  qualid [ident … ident] ::=expr
9.2 Semantics
Tactic expressions can only be applied in the context of a goal. The evaluation yields either a term, an integer or a tactic. Intermediary results can be terms or integers but the final result must be a tactic which is then applied to the current goal.
There is a special case for match goal expressions of which the clauses evaluate to tactics. Such expressions can only be used as end result of a tactic expression (never as argument of a non recursive local definition or of an application).
The rest of this section explains the semantics of every construction of Ltac.
Sequence
A sequence is an expression of the following form:
expr_{1} ; expr_{2}
The expressions expr_{1} and expr_{2} are evaluated to v_{1} and v_{2} which have to be tactic values. The tactic v_{1} is then applied and v_{2} is applied to every subgoal generated by the application of v_{1}. Sequence is leftassociative.
General sequence
A general sequence has the following form:
expr_{0} ; [ expr_{1}  ...  expr_{n} ]
The expressions expr_{i} are evaluated to v_{i}, for i=0,...,n and all have to be tactics. The tactic v_{0} is applied and v_{i} is applied to the ith generated subgoal by the application of v_{0}, for =1,...,n. It fails if the application of v_{0} does not generate exactly n subgoals.
Variants:
 If no tactic is given for the ith generated subgoal, it behaves as if the tactic idtac were given. For instance, split ; [  auto ] is a shortcut for split ; [ idtac  auto ].
 expr_{0} ; [ expr_{1}  ... 
expr_{i}  ..  expr_{i+1+j} 
...  expr_{n} ]
In this variant, idtac is used for the subgoals numbered from i+1 to i+j (assuming n is the number of subgoals).
Note that .. is part of the syntax, while ... is the metasymbol used to describe a list of expr of arbitrary length.
 expr_{0} ; [ expr_{1}  ... 
expr_{i}  expr .. 
expr_{i+1+j}  ...  expr_{n} ]
In this variant, expr is used instead of idtac for the subgoals numbered from i+1 to i+j.
For loop
There is a for loop that repeats a tactic num times:
do num expr
expr is evaluated to v. v must be a tactic value. v is applied num times. Supposing num>1, after the first application of v, v is applied, at least once, to the generated subgoals and so on. It fails if the application of v fails before the num applications have been completed.
Repeat loop
We have a repeat loop with:
repeat expr
expr is evaluated to v. If v denotes a tactic, this tactic is applied to the goal. If the application fails, the tactic is applied recursively to all the generated subgoals until it eventually fails. The recursion stops in a subgoal when the tactic has failed. The tactic repeat expr itself never fails.
Error catching
We can catch the tactic errors with:
try expr
expr is evaluated to v. v must be a tactic value. v is applied. If the application of v fails, it catches the error and leaves the goal unchanged. If the level of the exception is positive, then the exception is reraised with its level decremented.
Detecting progress
We can check if a tactic made progress with:
progress expr
expr is evaluated to v. v must be a tactic value. v is applied. If the application of v produced one subgoal equal to the initial goal (up to syntactical equality), then an error of level 0 is raised.
Error message: Failed to progress
Branching
We can easily branch with the following structure:
expr_{1}  expr_{2}
expr_{1} and expr_{2} are evaluated to v_{1} and v_{2}. v_{1} and v_{2} must be tactic values. v_{1} is applied and if it fails to progress then v_{2} is applied. Branching is leftassociative.
First tactic to work
We may consider the first tactic to work (i.e. which does not fail) among a panel of tactics:
first [ expr_{1}  ...  expr_{n} ]
expr_{i} are evaluated to v_{i} and v_{i} must be tactic values, for i=1,...,n. Supposing n>1, it applies v_{1}, if it works, it stops else it tries to apply v_{2} and so on. It fails when there is no applicable tactic.
Error message: No applicable tactic
Solving
We may consider the first to solve (i.e. which generates no subgoal) among a panel of tactics:
solve [ expr_{1}  ...  expr_{n} ]
expr_{i} are evaluated to v_{i} and v_{i} must be tactic values, for i=1,...,n. Supposing n>1, it applies v_{1}, if it solves, it stops else it tries to apply v_{2} and so on. It fails if there is no solving tactic.
Error message: Cannot solve the goal
Identity
The constant idtac is the identity tactic: it leaves any goal unchanged but it appears in the proof script.
Variant: idtac message_token … message_token
This prints the given tokens. Strings and integers are printed literally. If a (term) variable is given, its contents are printed.
Failing
The tactic fail is the alwaysfailing tactic: it does not solve any goal. It is useful for defining other tacticals since it can be catched by try or match goal.
Variants:

fail n
The number n is the failure level. If no level is specified, it defaults to 0. The level is used by try and match goal. If 0, it makes match goal considering the next clause (backtracking). If non zero, the current match goal block or try command is aborted and the level is decremented.  fail message_token … message_token
The given tokens are used for printing the failure message.  fail n message_token … message_token
This is a combination of the previous variants.
Error message: Tactic Failure message (level n).
Local definitions
Local definitions can be done as follows:
let ident_{1} := expr_{1}
with ident_{2} := expr_{2}
...
with ident_{n} := expr_{n} in
expr
each expr_{i} is evaluated to v_{i}, then, expr is evaluated by substituting v_{i} to each occurrence of ident_{i}, for i=1,...,n. There is no dependencies between the expr_{i} and the ident_{i}.
Local definitions can be recursive by using let rec instead of let. In this latter case, the definitions are evaluated lazily so that the rec keyword can be used also in non recursive cases so as to avoid the eager evaluation of local definitions.
Application
An application is an expression of the following form:
qualid tacarg_{1} ... tacarg_{n}
The reference qualid must be bound to some defined tactic definition expecting at least n arguments. The expressions expr_{i} are evaluated to v_{i}, for i=1,...,n.
Function construction
A parameterized tactic can be built anonymously (without resorting to local definitions) with:
fun ident_{1} ... ident_{n} => expr
Indeed, local definitions of functions are a syntactic sugar for binding a fun tactic to an identifier.
Pattern matching on terms
We can carry out pattern matching on terms with:
match expr with
cpattern_{1} => expr_{1}
 cpattern_{2} => expr_{2}
...
 cpattern_{n} => expr_{n}
 _ => expr_{n+1}
end
The expression expr is evaluated and should yield a term which is matched against cpattern_{1}. The matching is nonlinear: if a metavariable occurs more than once, it should match the same expression every time. It is firstorder except on the variables of the form @?id that occur in head position of an application. For these variables, the matching is secondorder and returns a functional term.
If the matching with cpattern_{1} succeeds, then expr_{1} is evaluated into some value by substituting the pattern matching instantiations to the metavariables. If expr_{1} evaluates to a tactic and the match expression is in position to be applied to a goal (e.g. it is not bound to a variable by a let in), then this tactic is applied. If the tactic succeeds, the list of resulting subgoals is the result of the match expression. If expr_{1} does not evaluate to a tactic or if the match expression is not in position to be applied to a goal, then the result of the evaluation of expr_{1} is the result of the match expression.
If the matching with cpattern_{1} fails, or if it succeeds but the evaluation of expr_{1} fails, or if the evaluation of expr_{1} succeeds but returns a tactic in execution position whose execution fails, then cpattern_{2} is used and so on. The pattern _ matches any term and shunts all remaining patterns if any. If all clauses fail (in particular, there is no pattern _) then a nomatchingclause error is raised.
Error messages:
 No matching clauses for match
No pattern can be used and, in particular, there is no _ pattern.
 Argument of match does not evaluate to a term
This happens when expr does not denote a term.
Variants:
 Using lazymatch instead of match has an effect if the righthandside of a clause returns a tactic. With match, the tactic is applied to the current goal (and the next clause is tried if it fails). With lazymatch, the tactic is directly returned as the result of the whole lazymatch block without being first tried to be applied to the goal. Typically, if the lazymatch block is bound to some variable x in a let in, then tactic expression gets bound to the variable x.

There is a special form of patterns to match a subterm against the
pattern:
context ident [ cpattern ]
It matches any term which one subterm matches cpattern. If there is a match, the optional ident is assign the “matched context”, that is the initial term where the matched subterm is replaced by a hole. The definition of context in expressions below will show how to use such term contexts.If the evaluation of the righthandside of a valid match fails, the next matching subterm is tried. If no further subterm matches, the next clause is tried. Matching subterms are considered topbottom and from left to right (with respect to the raw printing obtained by setting option Printing All, see Section 2.9).
Coq < Ltac f x :=
Coq < match x with
Coq < context f [S ?X] =>
Coq < idtac X; (* To display the evaluation order *)
Coq < assert (p := refl_equal 1 : X=1); (* To filter the case X=1 *)
Coq < let x:= context f[O] in assert (x=O) (* To observe the context *)
Coq < end.
f is defined
Coq < Goal True.
1 subgoal
============================
True
Coq < f (3+4).
2
1
2 subgoals
p : 1 = 1
============================
1 + 4 = 0
subgoal 2 is:
True

For historical reasons, context considers nary applications
such as (f 1 2) as a whole, and not as a sequence of unary
applications ((f 1) 2). Hence context [f ?x] will fail
to find a matching subterm in (f 1 2): if the pattern is a partial
application, the matched subterms will be necessarily be
applications with exactly the same number of arguments.
Alternatively, one may now use the following variant of context:
appcontext ident [ cpattern ]
The behavior of appcontext is the same as the one of context, except that a matching subterm could be a partial part of a longer application. For instance, in (f 1 2), an appcontext [f ?x] will find the matching subterm (f 1).
Pattern matching on goals
We can make pattern matching on goals using the following expression:
match goal with  hyp_{1,1},...,hyp_{1,m1} cpattern_{1}=> expr_{1}  hyp_{2,1},...,hyp_{2,m2} cpattern_{2}=> expr_{2} ...  hyp_{n,1},...,hyp_{n,mn} cpattern_{n}=> expr_{n} _ => expr_{n+1} end
If each hypothesis pattern hyp_{1,i}, with i=1,...,m_{1} is matched (nonlinear firstorder unification) by an hypothesis of the goal and if cpattern_{1} is matched by the conclusion of the goal, then expr_{1} is evaluated to v_{1} by substituting the pattern matching to the metavariables and the real hypothesis names bound to the possible hypothesis names occurring in the hypothesis patterns. If v_{1} is a tactic value, then it is applied to the goal. If this application fails, then another combination of hypotheses is tried with the same proof context pattern. If there is no other combination of hypotheses then the second proof context pattern is tried and so on. If the next to last proof context pattern fails then expr_{n+1} is evaluated to v_{n+1} and v_{n+1} is applied. Note also that matching against subterms (using the context ident [ cpattern ]) is available and may itself induce extra backtrackings.
Error message: No matching clauses for match goal
No clause succeeds, i.e. all matching patterns, if any, fail at the application of the righthandside.
It is important to know that each hypothesis of the goal can be matched by at most one hypothesis pattern. The order of matching is the following: hypothesis patterns are examined from the right to the left (i.e. hyp_{i,mi} before hyp_{i,1}). For each hypothesis pattern, the goal hypothesis are matched in order (fresher hypothesis first), but it possible to reverse this order (older first) with the match reverse goal with variant.
Variant:
Using lazymatch instead of match has an effect if the
righthandside of a clause returns a tactic. With match, the
tactic is applied to the current goal (and the next clause is tried if
it fails). With lazymatch, the tactic is directly returned as
the result of the whole lazymatch block without being first
tried to be applied to the goal. Typically, if the lazymatch
block is bound to some variable x in a let in, then tactic
expression gets bound to the variable x.
Coq < lazymatch goal with
Coq <  _ => idtac "here"; fail
Coq <  _ => idtac "wasn’t lazy"; trivial
Coq < end.
test_lazy is defined
Coq < Ltac test_eager :=
Coq < match goal with
Coq <  _ => idtac "here"; fail
Coq <  _ => idtac "wasn’t lazy"; trivial
Coq < end.
test_eager is defined
Coq < Goal True.
1 subgoal
============================
True
Coq < test_lazy  idtac "was lazy".
here
was lazy
1 subgoal
============================
True
Coq < test_eager  idtac "was lazy".
here
wasn’t lazy
Proof completed.
Filling a term context
The following expression is not a tactic in the sense that it does not produce subgoals but generates a term to be used in tactic expressions:
context ident [ expr ]
ident must denote a context variable bound by a context pattern of a match expression. This expression evaluates replaces the hole of the value of ident by the value of expr.
Error message: not a context variable
Generating fresh hypothesis names
Tactics sometimes have to generate new names for hypothesis. Letting the system decide a name with the intro tactic is not so good since it is very awkward to retrieve the name the system gave. The following expression returns an identifier:
fresh component … component
It evaluates to an identifier unbound in the goal. This fresh identifier is obtained by concatenating the value of the component’s (each of them is, either an ident which has to refer to a name, or directly a name denoted by a string). If the resulting name is already used, it is padded with a number so that it becomes fresh. If no component is given, the name is a fresh derivative of the name H.
Computing in a constr
Evaluation of a term can be performed with:
eval redexpr in term
where redexpr is a reduction tactic among red, hnf, compute, simpl, cbv, lazy, unfold, fold, pattern.
Typechecking a term
The following returns the type of term:
type of term
Accessing tactic decomposition
Tactical “info expr” is not really a tactical. For elementary tactics, this is equivalent to expr. For complex tactic like auto, it displays the operations performed by the tactic.
Proving a subgoal as a separate lemma
From the outside “abstract expr” is the same as solve expr. Internally it saves an auxiliary lemma called ident_subproofn where ident is the name of the current goal and n is chosen so that this is a fresh name.
This tactical is useful with tactics such as omega or discriminate that generate huge proof terms. With that tool the user can avoid the explosion at time of the Save command without having to cut manually the proof in smaller lemmas.
Variants:

abstract expr using ident.
Give explicitly the name of the auxiliary lemma.
Error message: Proof is not complete
Calling an external tactic
The tactic external allows to run an executable outside the Coq executable. The communication is done via an XML encoding of constructions. The syntax of the command is
external "command" "request" tacarg … tacarg
The string command, to be interpreted in the default
execution path of the operating system, is the name of the external
command. The string request is the name of a request to be
sent to the external command. Finally the list of tactic arguments
have to evaluate to terms. An XML tree of the following form is sent
to the standard input of the external command.
<REQUEST req="request"> 
the XML tree of the first argument 
… 
the XML tree of the last argument 
</REQUEST> 
Conversely, the external command must send on its standard output an XML tree of the following forms:
<TERM> 
the XML tree of a term 
</TERM> 
or
<CALL uri="ltac_qualified_ident"> 
the XML tree of a first argument 
… 
the XML tree of a last argument 
</CALL> 
where ltac_qualified_ident is the name of a
defined L_{tac} function and each subsequent XML tree is recursively a
CALL or a TERM node.
The Document Type Definition (DTD) for terms of the Calculus of Inductive Constructions is the one developed as part of the MoWGLI European project. It can be found in the file dev/doc/cic.dtd of the Coq source archive.
An example of parser for this DTD, written in the Objective Caml  Camlp4 language, can be found in the file parsing/g_xml.ml4 of the Coq source archive.
9.3 Tactic toplevel definitions
9.3.1 Defining L_{tac} functions
Basically, L_{tac} toplevel definitions are made as follows:
Ltac ident ident_{1} ... ident_{n} := expr
This defines a new L_{tac} function that can be used in any tactic script or new L_{tac} toplevel definition.
Remark: The preceding definition can equivalently be written:
Ltac ident := fun ident_{1} ... ident_{n} => expr
Recursive and mutual recursive function definitions are also possible with the syntax:
Ltac ident_{1} ident_{1,1} ... ident_{1,m1} := expr_{1}
with ident_{2} ident_{2,1} ... ident_{2,m2} := expr_{2}
...
with ident_{n} ident_{n,1} ... ident_{n,mn} := expr_{n}
It is also possible to redefine an existing userdefined tactic
using the syntax:
Ltac qualid ident_{1} ... ident_{n} ::= expr
A previous definition of qualidmust exist in the environment. The new definition will always be used instead of the old one and it goes accross module boundaries.
If preceded by the keyword Local the tactic definition will not be exported outside the current module.
9.3.2 Printing L_{tac} tactics
Defined L_{tac} functions can be displayed using the command
Print Ltac qualid.
9.4 Debugging L_{tac} tactics
The L_{tac} interpreter comes with a stepbystep debugger. The debugger can be activated using the command
Set Ltac Debug.
and deactivated using the command
Unset Ltac Debug.
To know if the debugger is on, use the command Test Ltac Debug. When the debugger is activated, it stops at every step of the evaluation of the current L_{tac} expression and it prints information on what it is doing. The debugger stops, prompting for a command which can be one of the following:
simple newline:  go to the next step 
h:  get help 
x:  exit current evaluation 
s:  continue current evaluation without stopping 
rn:  advance n steps further 