Commit graph

7 commits

Author SHA1 Message Date
Mario Carneiro
7ace147f25 refactor(init/meta/tactic): replace assertv -> note, definev -> pose 2017-05-14 19:34:27 -07:00
Leonardo de Moura
5cef84709f refactor(library): avoid auxiliary definitions such as add/mul/le/etc
See Section "Other goodies" at
https://github.com/leanprover/lean/wiki/Refactoring-structures

This commit also improves the support for projections in the
unifier/matcher.

Now, we consider the extra case-split for projections.
Given a projection `proj`, and the constraint `proj s =?= proj t`, we need to try first `s =?= t` and if it fails, then try to reduce.
This is needed in the standard library because we now have constraints such as:
```
@has_le.le ?A ?s ?a ?b  =?=  @has_le.le nat nat.has_add x y
```
If we reduce the right hand side, we get the unsolvable constraint
```
@has_le.le ?A ?s ?a ?b  =?=  nat.le x y
```
Before this change, the constraint was `@le ?A ?s ?a ?b  =?=  @le nat nat.has_add x y`, and we already perform a case-split in this case.
Moreover, projections were eagerly reduced whenever possible.
The extra case-split generates a performance problem in several tests. For example `fib 8 = 34` was timing out.
I worked around this issue by performing the case-split only when the constraint contains meta-variables.
There are also minor issues. Example. `<` is notation for `has_lt.lt`, but `>` is for `gt`.
2017-05-01 08:52:19 -07:00
Leonardo de Moura
f650a1b873 refactor(library/init/meta): avoid '_core' idiom using default parameters
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?
2017-02-14 09:46:55 -08:00
Gabriel Ebner
a586cadfa1 chore(tests/lean/run/super_examples): clean up 2017-01-10 09:07:37 -08:00
Gabriel Ebner
890ba702e6 feat(tools/super/demod): demodulation 2017-01-10 09:07:37 -08:00
Gabriel Ebner
244e061f76 refactor(tools/super/simp): do not enable simp by default
simp interacts badly with super's term ordering.  I believe a better
approach is to pick the term ordering according to the available simp
rules, as in "More SPASS with Isabelle".
2017-01-10 09:07:37 -08:00
Leonardo de Moura
4b97b00536 refactor(library/tools/super): move examples to test folder 2016-12-16 19:05:32 -08:00
Renamed from library/tools/super/examples.lean (Browse further)