max/lean4-htt
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions 2
16813 commits 1 branch 0 tags 5.3 GiB
Commit graph

3077 commits

Author SHA1 Message Date
Leonardo de Moura
45dc2cd49a feat(library/init/lean/compiler): [export] attribute in Lean 2019-06-24 15:48:12 -07:00
Leonardo de Moura
714468dc60 chore(frontends/lean): remove include and omit commands 2019-06-24 15:48:11 -07:00
Leonardo de Moura
af2d6dbd45 chore(library/init): avoid local attribute 2019-06-24 15:48:11 -07:00
Leonardo de Moura
94bca2b9d8 chore(library/init): mimize use of notations 2019-06-24 15:48:11 -07:00
Leonardo de Moura
dda0e38802 chore(library/init): avoid local notation 2019-06-24 15:48:11 -07:00
Leonardo de Moura
da09ef4f66 feat(frontends/lean/builtin_exprs): minor improvement 2019-06-24 15:48:11 -07:00
Leonardo de Moura
8f1345dc53 chore(library/init/lean/syntax): simplify SyntaxNodeKind 2019-06-21 14:24:44 -07:00
Leonardo de Moura
e4344b0c94 chore(library/init/lean/parser/default): update default 2019-06-21 14:20:40 -07:00
Leonardo de Moura
0fe8fd1307 feat(library/init/lean/parser/parser): notation 2019-06-21 14:20:22 -07:00
Leonardo de Moura
43fd0eeb94 chore(library/init/coe): minor 2019-06-21 14:15:26 -07:00
Leonardo de Moura
bc9e460f62 fix(library/init/lean/compiler/ir): collectUsedDecls must take initialization functions into account 
Move builtin parser level to its own directory
 2019-06-21 13:34:42 -07:00
Leonardo de Moura
93e5746739 chore(library/init/lean/parser/parser): naming consistency 2019-06-20 16:47:55 -07:00
Leonardo de Moura
98879f1580 refactor(library/init/lean/parser/parser): simplify SyntaxNodeKind 
The numeric `id` generation is works well for builtin parsers, but it
creates problems when defining dynamic ones.
 2019-06-20 14:51:59 -07:00
Leonardo de Moura
4ab31275a4 chore(library/init, frontends/lean): remove foldl and foldr notation, and implement list notation in the old parser 2019-06-20 14:32:08 -07:00
Leonardo de Moura
9e73d92e42 chore(library/init): remove instances of scoped notation 2019-06-20 14:08:35 -07:00
Leonardo de Moura
00aa2a3ffe chore(library/user_recursors): remove [recursor] attribute and environment extension 2019-06-20 11:25:53 -07:00
Leonardo de Moura
1e30f76511 chore(frontends/lean/pp): remove ppAsAnonymousCtor attribute 2019-06-20 11:03:20 -07:00
Leonardo de Moura
ac43b82668 chore(library/init): remove [derive] uses 
Trying to minimize the number of features we need to support in the new
frontend, and attributes we need to port to the new attribute manager.
 2019-06-20 10:53:15 -07:00
Leonardo de Moura
0b99a18f97 chore(library): use >> as notation for andthen 
We have other plans for `;`.
 2019-06-20 09:54:53 -07:00
Leonardo de Moura
8724a8cfd5 feat(library/init/lean/parser/parser): builtin parser attributes must be applied after compilation 2019-06-20 09:22:03 -07:00
Leonardo de Moura
e0ddacfd3e feat(library/init/lean/attributes,frontends/lean): allow attributes to specify when they should be applied 2019-06-20 09:17:03 -07:00
Leonardo de Moura
e86e6af049 feat(library/init/lean/attributes): add applicationTime field and remove unnecessary parameters 2019-06-20 08:48:26 -07:00
Leonardo de Moura
d7fb0aa908 feat(library/init/lean/parser/parser): simpler cache 
cc @kha
 2019-06-19 16:48:18 -07:00
Leonardo de Moura
f180b3f32e feat(library/init/lean/parser/parser): improve error messages on prattParser 2019-06-19 16:36:18 -07:00
Leonardo de Moura
4db487fb42 fix(library/init/lean/parser/parser): sepBy1 2019-06-19 16:34:49 -07:00
Leonardo de Moura
cf9a29152d fix(library/init/lean/parser/parser): ParserInfo for ident, strLit, and numLit 2019-06-19 16:19:00 -07:00
Leonardo de Moura
401de35b6c chore(library/init/lean/parser/parser): remove unnecessary import 
It turns out we don't need evalConst for implementing `builtinParsers`.
 2019-06-19 10:53:51 -07:00
Leonardo de Moura
5f014415a9 feat(library/init/lean/parser/parser): add helper functions for invoking builting parsers 
TODO: add scoped attributes for dynamically extending parsers.
 2019-06-19 10:48:19 -07:00
Leonardo de Moura
89dae7f877 fix(library/init/lean/parser/parser): missing result 2019-06-19 10:33:53 -07:00
Leonardo de Moura
451ab72eea fix(library/init/lean/attributes): typo 2019-06-19 10:21:40 -07:00
Leonardo de Moura
a55251618a fix(library/init/lean): missing file 2019-06-19 09:53:34 -07:00
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
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
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
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
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
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
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