| Commit message (Collapse) | Author | Age |
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Using dummy comment to @raise to please ocamldoc. Please change MS or
PMP, if needed.
|
| |
|
|
|
|
|
|
|
| |
In particular, a proof of the equivalence of excluded-middle and an
unrestricted principle of minimization.
Credits to Arnaud Spiwack for the ideas and formalizations of the proofs.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- prod_applist
- prod_applist_assum
- lambda_applist
- lambda_applist_assum
expect an instance matching the quantified context. They are now in
term.ml, with "list" being possibly "vect".
Names are a bit arbitrary. Better propositions are welcome. They are
put in term.ml in that reduction is after all not needed, because the
intent is not to do β or ι on the fly but rather to substitute a λΓ.c
or ∀Γ.c (seen as internalization of a Γ⊢c) into one step,
independently of the idea of reducing.
On the other side:
- beta_applist
- beta_appvect
are seen as optimizations of application doing reduction on the fly
only if possible. They are then kept as functions relevant for
reduction.ml.
|
|
|
|
|
| |
to c71aa6b and 6ababf) so as to rely on generic functions rather than
re-doing the de Bruijn indices cooking locally.
|
|
|
|
|
|
|
|
| |
It will later be used to fix a bug and improve some code.
Interestingly, there were a redundant semantic equivalent to
extended_rel_list in the kernel called local_rels, and another private
copy of extended_rel_list in exactly the same file.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Redefining adjust_subst_to_rel_context from instantiate_context who
was hidden in inductiveops.ml, renamed the latter into
subst_of_rel_context_instance and moving them to Vars. The new name
highlights that the input is an instance (as for applist) and the
output a substitution (as for substl). This is a clearer unified
interface, centralizing the difficult de-Bruijn job in one place. It
saves a couple of List.rev.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Related questions:
- What balance to find between precision and conciseness?
- What convention to follow for typesetting the different components
of the documentation is unclear?
New tentative type substl to emphasize that substitutions (for substl)
are represented the other way round compared to instances for
application (applist), though there are represented the same way
(i.e. most recent/dependent component on top) as instances of evars
(mkEvar).
Also removing unused subst*_named_decl functions (at least
substnl_named_decl is somehow non-sense).
|
| |
|
| |
|
| |
|
|
|
|
|
| |
next to each other, waiting for possible integration into a more
uniform API.
|
|
|
|
|
| |
cleaning the interfaces is eventually easier. Here, adding
find_mrectype_vect to simplify vnorm.ml.
|
| |
|
|
|
|
| |
characters.
|
| |
|
|
|
|
|
|
| |
Actually, we never mix the various uses of each dynamic type created through
the Dyn module. To enforce this statically, we functorize the Dyn module so
that we recover a fresh instance at each use point.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
It was not used in Coq codebase, and the only known user was ssreflect up
to commit 95354e0dee.
|
| |
|
|\ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
pat/c1/.../cn behaves as intro H; apply c1, ... , cn in H as pat.
Open to other suggestions of syntax though.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
constraints at the time of Next Obligation/Solve Obligations so that
interleaving definitions and obligation solving commands works properly.
|
| |
| |
| |
| |
| |
| |
| | |
using the wrong context.
This is very bad style but currently unavoidable, at least we don't
throw an anomaly anymore.
|
| |
| |
| |
| | |
projections (off by default).
|
| |
| |
| |
| | |
using dot notation.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
longer stable w.r.t. equality constraints as the universe graph will
choose different canonical levels depending on the equalities given to
it (l = r vs r = l).
|
| | |
|
| | |
|
| | |
|
|\| |
|
| | |
|