+ Coq breakpoints library.
+ Big and complex functions sometimes appearing during
+developement may contain bugs. Proving their correctness
+can be very hard, especially when Coq is used as a programming
+language with rich types, not as proof assistant.
+ This library allows one to prevent reduction of expressions
+of interest. This is achieved by wrapping them in so called
+"breakpoints", either modifying source code of function or
+ Then programmer can look at partial reduction's results, allow
+reduction of some/all breakpoint(s), list present breakpoints,
+watch at what these breakpoints are "waiting for"
+(beta/iota/zeta reduction), apply conversion tactic to expression
+under some/all breakpoint(s).
+ Usual alternatives are:
+ - debug with eyes, paper and pencil. Hard for big functions
+ - add debug prints in extracted code. Requires extraction
+ and patching extracted sources manually. Repeat when
+ function's body is changed.
+ - use "writer monad". Programmer must change types, use monadic
+ bind instead of some function applications, monadic return
+ instead of simply returning function's value. However this
+ approach is useful when debug information should be present
+ (know more? Please tell me about them!)
+ Internally breakpoint is represented as an opaque wrapper
+containing expression. Coq doesn't unfold breakpoints until
+programmer won't tell him to do this.
+ There are two modules, for named and for nameless breakpoints.
+Names are not required sometimes, since they can clutter the
+output. However it's impossible to manipulate specific nameless
+breakpoints, only "for all breakpoints" commands.
+ Require Import Breakpoints.
+ Then, for named breakpoints:
+ Open Scope string_scope. (* for convenience *)
+ For nameless breakpoints:
+ (note: file "Bp_examples.v" contains examples on how to use
+ these definitions/tactics.)
+ This section contains documentation on both named and nameless
+breakpoints. Each description states on what kind of breakpoints
+the definition/tactic is applicable. Don't mix named breakpoints
+ is an expression of sort Type, useful to start a debug
+ session using vernacular 'Goal DEBUG <expr>.'
+ ("Lemma somelemma : DEBUG <expr>." is fine too -- just
+ enter the proof mode with breakpoints in the goal,
+ "DEBUG" is just a convenience keyword.)
+ for named breakpoints it is a wrapper for <expr> that
+ won't be unfolded by Coq until 'pass "name".' or
+ 'pass_all.' (see below).
+ same as 'BREAK "name" <expr>', but for nameless breakpoints.
+ Following commands can be used in proof mode:
+ for named breakpoints: lists breakpoints present in the
+ for nameless breakpoints: shows presence/absence of
+ breakpoints in the current goal.
+ lists breakpoints and their positions in the goal:
+ breakpoint is an argument of some function
+ breakpoint is a function
+ breakpoint present in match construction as a
+ "match_item" -- expression that will be "destructed"
+ breakpoint is a right-hand side of some
+ "let lhs := rhs in expr" expression
+ - under_break "name" ltac:(fun e => eval <redexp> in e).
+ reduces expression wrapped in breakpoint "name" with
+ conversion tactic <redexp> (like "simpl", "cbv ..."
+ - under_all_breaks ltac:(fun e => eval <redexp> in e).
+ same as 'under_break "name" ...", but for all named
+ - under_break ltac:(fun e => eval <redexp> in e).
+ same as 'under_break "name" ...', but for nameless
+ allow some/all breakpoints to be reduced by Coq:
+ for breakpoint with name "name"
+ for all breakpoints (named/nameless)
+ for all nameless breakpoints
+ - set_break "name" <expr>.
+ sets named breakpoint "on fly".
+ sets nameless breakpoint "on fly".
+ Finishes the debug session, allows one to store it for
+ later debugging, with "Defined." / "Qed".
+ Coq "conversion tactics" are very useful during debug
+session, most notably "cbv" tactic which can be fine-tuned
+to make Coq do only needed reductions.
+ See the file "Bp_examples.v".
+ Breakpoints that use fixpoint's arguments can't be manipulated:
+they are not seen in "breaks", "waits", can't be "pass"'ed.
+ Why? Take a look at an example:
+ Goal (fix f (x : nat) := id x) 1 = 1.
+ | |- appcontext [@id] => idtac "works"
+ | _ (* match failback *) => idtac "doesn't work"
+ It's a Coq bug probably, it is already reported:
+ - Dmitry Grebeniuk <email@example.com>