This command is not just a cosmetic feature.
We need it to defined `id_rhs` before the tactic framework is defined.
We want `id_rhs` to be used in all definitions generated by the equation
compiler. Right now, it is only used in definitions defined after the
tactic framework.
`{s with ...}` is now `{..., ..s}`, which more clearly expresses that the
result type is not necessarily equal to the type of `s` (in absence of an
expected type and a structure name, we still default to the type of `s`).
Multiple fallback sources can be given: `{..., ..s, ..t}` will fall back to
searching a field in `s`, then in `t`. The last component can also be `..`,
which will replace any missing fields with a placeholder.
The old notation will be removed in the future.
Holes {! ... !} are elaborated using `sorry`.
We report an error if their value is fixed by typing and/or
elaboration rules.
We store the tactic_state and the optional attribute in the
info_manager. The idea is to allow users to execute commands with
respect to the stored tactic state and optional attribute.
The optional attribute is a pre term.
We are planning to add commands such as:
- Check type of the given argument.
- Reduce the given argument.
- Synthesize the hole automatically, where the given argument encodes
hint to the synthesizer.
- Use the given argument to fill the hole.
I kept a few core methods (e.g., exact_core and apply_core). Reason:
if we use default parameters
meta constant exact (e : expr) (md := semireducible) : tactic unit
then, we will not be able to write
to_expr p >>= exact
The workaround is
do t <- to_expr p, exact t
or
to_expr p >>= (fun x, exact x)
One alternative is to change how we handle default parameters, and
eta-expand applications that involve default parameters.
We may also have an attribute [eta_expand]. Then
attribute [eta_expand] foo
instructs the elaborator to automatically eta-expand foo-applications.
The attribute would give users more control, and avoid potential
performance problems. Without the attribute, then for every function
application the elaborator has to check the type and decide whether it
must be eta-expanded or not.
@gebner @kha What do you think?
(Type u) is the old (Type (u+1))
(PType u) is the old (Type u)
Type* is the old (Type (_+1))
PType* is the old Type*
The stdlib can be compiled, but we still have > 70 broken tests
See discussion at #1341
In Lean2, we used to cache elaborated definitions in .clean files. The
main goal was to optimize each flycheck invocation produced by Emacs.
The Lean3 definition package was not updating this cache. Moreover, it
is not necessary because the new compilation server subsumes it.
