Commit graph

16763 commits

Author SHA1 Message Date
Leonardo de Moura
697f69020f fix(library/init/lean/parser/parser): new registerBuiltinParserAttribute
It is still broken since we apply attributes before we compile code.

Recall that attributes such as `@[export]` and `@[extern]` must be applied before we
compile code.

On the other hand, any attribute `attrName`
```
@[attrName] def foo := ...
```
which creates auxiliary definitions that depend on `foo` must be applied
AFTER we generate code for `foo`. Otherwise, we will fail to compile the
auxiliary definition since we don't have code for `foo` yet.

I will fix the issue above by allowing attributes to specify when they
should be applied. I will start with only two options: before and after
code compilation. In the future, we may need more options (e.g., before
elaboration), but I don't see the need yet.

cc @kha
2019-06-19 09:52:56 -07:00
Leonardo de Moura
766467d095 fix(stage0): missing files 2019-06-18 18:35:18 -07:00
Leonardo de Moura
08cdb757b4 feat(library/init/lean/environment): add Environment.addAndCompile
To fix `BuiltinParserAttribute`, we need to be able to add auxiliary declarations programmatically.
2019-06-18 18:20:17 -07:00
Leonardo de Moura
66e3f68dbc chore(library/compiler/procedure): remove dead code 2019-06-18 17:29:19 -07:00
Leonardo de Moura
dbe7078e80 feat(library/init/lean/attributes): add ParametricAttribute.setParam 2019-06-18 17:24:16 -07:00
Leonardo de Moura
0dfca42f6d chore(library/init/lean/compiler/initattr): remove unnecessary @[export] 2019-06-18 16:15:48 -07:00
Leonardo de Moura
9da080d398 feat(library/compiler/init_attribute): switch to @[init] attribute in Lean 2019-06-18 16:03:52 -07:00
Leonardo de Moura
6219a2277a fix(library/init/lean/compiler/initattr): getInitFnNameFor 2019-06-18 16:03:52 -07:00
Leonardo de Moura
696088cf2e feat(library/init/lean/compiler/initattr): @[init] attribute in Lean 2019-06-18 16:03:52 -07:00
Leonardo de Moura
a03c236380 feat(library/init/lean/compiler/initattr): new @[init] attribute validation 2019-06-18 15:40:16 -07:00
Leonardo de Moura
2b453de299 fix(frontends/lean/decl_attributes): remove mdata 2019-06-18 15:25:34 -07:00
Leonardo de Moura
91821529c0 feat(library/init/lean/compiler/initattr): register new @[init] attributre using new attribute manager
This is just the basic skeleton for testing
2019-06-18 15:20:17 -07:00
Leonardo de Moura
50f8d232c3 feat(frontends/lean/decl_attributes): add expr_to_syntax 2019-06-18 15:17:46 -07:00
Leonardo de Moura
89738ac344 feat(library/init/lean/attributes): add ParametricAttribute 2019-06-18 12:49:53 -07:00
Leonardo de Moura
444d942b1c fix(library/init/lean/parser/parser): bootstrapping/initialization issue
`evalConst` was being invoked "too early".
2019-06-18 11:27:37 -07:00
Leonardo de Moura
14e902cf8e feat(library/init/lean/parser): register builtin parsing tables 2019-06-18 09:25:10 -07:00
Leonardo de Moura
03ca8734f3 feat(library/init/lean/parser/parser): add runParser for testing 2019-06-18 09:01:58 -07:00
Leonardo de Moura
b558ac424f feat(library/init/lean/parser/parser): add prattParser 2019-06-18 08:37:15 -07:00
Leonardo de Moura
e9535e5792 feat(library/init/lean/parser/parser): add longestMatch combinator 2019-06-18 08:07:46 -07:00
Leonardo de Moura
e9b877c334 feat(library/init/lean/parser/parser): add registerBuiltinParserAttribute 2019-06-17 16:49:44 -07:00
Leonardo de Moura
a495a4ce86 feat(library/init/lean/parser/parser): new parser combinators based on tests/playground/parser
Main differences with respect to `tests/playground/parser`

1- There is a single (parametric) parser type: `Parser k`, where `k` is
   used to identify whether it is a `nud` or `led` parser.
2- It assumes parsing tables are stored in the `Environment`.
3- We check precedence mismatch, and use the value `none` to represent
   "use existing precedence".
4- We have support for silent (aka epsilon) parsing actions.

Remark: the experiments at `tests/playground/parser` demonstrated that the new
parsing infrastructure is at least 10x faster than the one based on the
`Parsec` monad.
2019-06-17 13:29:01 -07:00
Leonardo de Moura
36aa33091b chore(stage0): update 2019-06-07 17:16:36 -07:00
Leonardo de Moura
f176a7963c feat(library/init/lean/compiler/ir/emitcpp): register arity 0 declarations 2019-06-07 17:15:16 -07:00
Leonardo de Moura
3651dc7618 feat(library/init/lean): add evalConst
The implementation is good enough for implementing extensible parsers,
elaborators and tactics, but there are a few TODOs

1- We should have a better story for standalone applications.
   Most of them don't need `evalConst`, and the global table is
   just initialization overhead.

2- The global table introduces a dependency on the `Lean.Name`
   implementation. So, all standalone applications will depend on it.

3- We are not storing arity 0 constants in the table.
   This one should be easy to fix in the future.
2019-06-07 16:31:28 -07:00
Leonardo de Moura
c3a7cc4617 feat(library/init/lean/compiler/ir/emitcpp): register functions 2019-06-07 15:34:55 -07:00
Leonardo de Moura
b2ae4c51af chore(shell/lean): cleanup 2019-06-07 14:52:16 -07:00
Leonardo de Moura
e080909ba7 chore(gen/apply): move to script 2019-06-07 11:05:14 -07:00
Leonardo de Moura
9ac18251f8 chore(src/sexpr): remove sexpr 2019-06-07 11:00:00 -07:00
Leonardo de Moura
d664486eca chore(util): move format to src/util 2019-06-07 10:58:23 -07:00
Leonardo de Moura
12809945ba chore(util/sexpr/format): use Lean implementation 2019-06-07 10:45:42 -07:00
Leonardo de Moura
373011bc20 chore(library/init/lean/format): export group 2019-06-07 10:35:04 -07:00
Leonardo de Moura
5eaca0d89e chore(util/sexpr/format): preparing to switch to Lean implementation 2019-06-07 10:18:23 -07:00
Leonardo de Moura
452485a706 chore(library/init/lean/format): export functions 2019-06-07 10:10:13 -07:00
Leonardo de Moura
aadb07d5e4 chore(tests/lean): remove/fix tests 2019-06-07 09:56:11 -07:00
Leonardo de Moura
3afa4f7ab0 chore(util/safe_arith): remove dead code 2019-06-07 09:52:31 -07:00
Leonardo de Moura
f6b9a0fe9c chore(util/sexpr/format): preparing to switch to Lean implementation 2019-06-07 09:46:34 -07:00
Leonardo de Moura
7beb74fb0f chore(util/sexpr/format): remove dead code 2019-06-07 09:28:30 -07:00
Leonardo de Moura
ff86159297 test(tests/playground/eval): proof of concept for a safe eval function 2019-06-06 17:06:32 -07:00
Leonardo de Moura
0553d60dbf feat(library/compiler/util): switch to new attributes implemented in Lean 2019-06-06 15:40:39 -07:00
Leonardo de Moura
b292fc13cc chore(library/init/lean/compiler/inline): export typo 2019-06-06 15:28:20 -07:00
Leonardo de Moura
e4063f5eec chore(stage0): update 2019-06-06 15:20:13 -07:00
Leonardo de Moura
d74f52e8dd feat(library/init/lean/parser/identifier): add indentifier.lean back 2019-06-06 15:18:22 -07:00
Leonardo de Moura
f0bb48a48a chore(library/init/lean/parser/trie): put trie back 2019-06-06 15:14:27 -07:00
Leonardo de Moura
8f9b73399b feat(library/compiler/eager_lambda_lifting): implement using Lean version 2019-06-06 15:09:57 -07:00
Leonardo de Moura
57e250a768 chore(stage0): remove leftover 2019-06-06 15:09:41 -07:00
Leonardo de Moura
9b457cc77c feat(library/init/lean/compiler/inline): implement tester functions and export them 2019-06-06 15:07:08 -07:00
Leonardo de Moura
dbe38b054d feat(library/init/lean/name): add Lean version of name::append_after 2019-06-06 14:28:59 -07:00
Leonardo de Moura
1658be20f1 feat(library/init/data/string): add String.isPrefixOf 2019-06-06 14:20:50 -07:00
Leonardo de Moura
72290483e4 chore(library/init/lean/compiler): attributes.lean ==> inline.lean 2019-06-06 14:08:13 -07:00
Leonardo de Moura
e05cdc2b08 feat(library/init/lean/compiler): declare function inlining attributes in Lean
Remark: they are not active yet since we haven't removed the ones
defined in C++ yet.
2019-06-06 11:05:54 -07:00