Leonardo de Moura
9d5b69ad5c
fix(library/compiler/preprocess): compile_lemma => compile_irrelevant
...
We can also ignore functions that return types at compile_lemma (now
called compile_irrelevant).
fixes #1658
2017-06-12 20:33:31 -07:00
Sebastian Ullrich
0ca6e2c96f
refactor(library/{type_context,compiler/preprocess},frontends/lean/elaborator): use opaque, general type class instead of special app elaboration for eval_expr
2017-04-27 16:04:59 -07:00
Sebastian Ullrich
5d68938a9c
feat(frontends/lean): expr literals ```(...)
2017-03-05 08:37:16 -08:00
Leonardo de Moura
22988bb95d
feat(library/compiler): avoid pack/unpack overhead produced by the inductive_compiler in the code generator
...
TODO: make sure the user is not manually using cases_on for the
auxiliary datatype generated by the inductive_compiler to
destruct nested inductives.
2017-03-04 13:54:44 -08:00
Leonardo de Moura
184d505d51
fix(library/compiler/preprocess): do not unfold noncomputable definitions in the compiler
...
see #1401
2017-02-26 22:05:16 -08:00
Leonardo de Moura
622e9a6035
feat(library/type_context): use m_unfold_pred to decide whether macros should be unfolded or not
...
see #1394
2017-02-21 18:07:39 -08:00
Sebastian Ullrich
9d8c84713c
refactor(*): reduce exception context info from expr to pos_info
2017-02-17 13:45:57 +01:00
Sebastian Ullrich
5ed1ac924c
feat(frontends/lean/elaborator): support partially applied eval_expr
2017-02-17 13:03:47 +01:00
Leonardo de Moura
368e2bce80
feat(library/compiler/preprocessor): ignore propositions in the preprocessor
...
Suppose we have
def foo : some_proposition :=
by non_trivial_automation
Moreover, assume non_trivial_automation generates a huge proof.
Since this definition is marked with `def`, it is sent to the VM
compiler. In this kind of scenario, the compiler preprocessor was
spending a long time applying "useless" preprocessing steps.
We say they are useless because in the end everything is erased.
I think we should make sure every definition has some bytecode
associated with it in the VM even if the type of the definition
is a proposition. In this way, we have a simple invariant:
every definition has a vm_decl associated with it.
So, we workaround the performance problem above by short-circuiting
the preprocessor for propositions.
2017-02-15 22:11:53 -08:00
Leonardo de Moura
707cf45a26
refactor(library/type_context): rename whnf_pred => whnf_head_pred
2017-02-15 20:20:27 -08:00
Leonardo de Moura
a8c91aa6fc
fix(library/compiler/preprocess): expand eq.cases_on
...
The code generator was failing to erase eq.cases_on.
2017-02-07 21:19:01 -08:00
Leonardo de Moura
3178f41cce
fix(library/compiler/inliner): applications of definitions marked as [inline] are inlined even if they are not fully applied
...
see #1316
2017-01-17 16:33:19 -08:00
Leonardo de Moura
1f2b8745dc
fix(library/compiler): prevent let-expressions from being expanded
2017-01-12 11:18:16 -08:00
Leonardo de Moura
6e3959de2f
feat(library/compiler): create declarations for nested values
2016-12-12 10:37:58 -08:00
Leonardo de Moura
028bf36152
feat(library/compiler): eliminate unused let declarations
2016-12-12 08:23:37 -08:00
Leonardo de Moura
fbc1bb4d89
perf(library/compiler): add common subexpression elimination
...
It addresses a performance problem reported by Brian (huffman@galois.com ).
2016-12-11 14:43:51 -08:00
Leonardo de Moura
62d6b88570
fix(library/compiler/preprocess): make sure let-expressions are not expanded in the compiler preprocessor
2016-11-22 10:24:13 -08:00
Leonardo de Moura
d6000416f8
feat(library/compiler,frontends/lean/elaborator): (try to) preserve position information
...
We will use this information in the debugger.
2016-11-09 16:51:48 -08:00
Leonardo de Moura
6ce00a9b45
fix(library/compiler): move inliner to the beginning
...
Reason: the inliner may introduce recursors, non eta-expanded terms,
etc. Before this commit, it was "undoing" previous compilation steps.
2016-11-08 16:14:01 -08:00
Leonardo de Moura
9d3aa5b627
fix(library/compiler/elim_recursors): bug in elim_recursors
...
We may fail to type check auxiliary definitions that use rec_fn_macro.
The problem is that this macro cannot be unfolded.
So, we fix the problem by not type checking them. We add them as
constants, and store the definition in an auxiliary vector.
2016-11-02 14:19:28 -07:00
Leonardo de Moura
7465529445
feat(library/tactic): 'eval_expr' tactic skeleton
2016-10-03 16:26:28 -07:00
Leonardo de Moura
2ac2badd58
fix(library/compiler/preprocess): do not unfold proofs
2016-09-13 08:47:39 -07:00
Leonardo de Moura
567d6824f4
chore(library/compiler/preprocess): mark assertions as conditional
...
is_def_eq may take a very long time after the transformations are applied.
2016-09-03 16:15:22 -07:00
Leonardo de Moura
713c97a3be
fix(library/compiler/preprocess): make sure no_confusion is not expanded by expand_aux
2016-05-25 17:57:17 -07:00
Leonardo de Moura
abd2bbab78
feat(library/compiler/preprocess): expand auxiliary declarations automatically created by Lean (e.g., transitivite instances)
...
These declarations do not have VM bytecode associated with them.
Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2016-05-25 17:09:16 -07:00
Leonardo de Moura
752c81a166
fix(library/compiler/nat_value): add expand method, otherwise we may fail to type check terms using nat_value_macro
2016-05-13 12:50:28 -07:00
Leonardo de Moura
df9352ea6e
feat(library/compiler): better support for numeric constants
2016-05-12 16:33:37 -07:00
Leonardo de Moura
f2af5828ba
refactor(library/compiler): preprocess_rec ==> preprocess
2016-05-12 16:03:39 -07:00
