Commit graph

32 commits

Author SHA1 Message Date
Leonardo de Moura
f546b13b6c fix(library/init/lean/syntax): setTailInfo, getHeadInfo and getTailInfo 2019-08-08 20:55:29 -07:00
Leonardo de Moura
d8f295d980 feat(library/init/lean): helper functions for transforming Syntax objects 2019-08-08 20:11:57 -07:00
Leonardo de Moura
a2956f5bd6 feat(library/init/lean/syntax): add mrewriteBottomUp and rewriteBottomUp 2019-08-08 18:58:43 -07:00
Leonardo de Moura
46f361daab feat(library/init/lean/elaborator): add open command elaborator 2019-07-31 15:58:04 -07:00
Leonardo de Moura
cf8daf4b24 feat(library/init/lean/elaborator): process header
TODO:
- improve/fix `setSearchPath`
- add `IO.getEnv`
- add support for relative imports at `absolutizeModuleName`
2019-07-24 07:37:33 -07:00
Leonardo de Moura
fdb2fb3f0d chore(library/init/lean): add helper function 2019-07-21 08:21:20 -07:00
Leonardo de Moura
a535d348de feat(library/init/lean/elaborator): use SyntaxNode to define TermElab and CommandElab 2019-07-21 07:29:41 -07:00
Leonardo de Moura
35d841e6ea chore(library/init/lean/syntax): change default to Empty 2019-07-20 06:57:48 -07:00
Leonardo de Moura
76c27c9aa4 feat(library/init/lean/syntax): update preresolved field
The `Nat` is for handling the ambiguous `.` notation in Lean during
preresolution. Recall that `x.y` may represent a hierarchical name or
a "field access".
2019-07-19 11:11:50 -07:00
Leonardo de Moura
f9459f6e93 feat(library/init/lean/syntax): add Syntax.other
We will use this feature to implement the new elaborator.
An elaborator produces `Syntax Expr` instead of `Syntax`.
2019-07-19 10:45:01 -07:00
Leonardo de Moura
52484248a0 chore(library/init/lean/syntax): formatting 2019-07-16 07:26:49 -07:00
Leonardo de Moura
f206b30fd7 feat(library/init/lean/parser): add charLit 2019-07-16 07:22:09 -07:00
Leonardo de Moura
b2e1ff8b3e feat(library/init): use new "empty match" syntax 2019-07-15 16:25:14 -07:00
Leonardo de Moura
a8c36d4c29 feat(library/init/lean/syntax): remove MacroScopes
We are going to use a simpler approach to help users writing hygienic
macros. Suppose we have a syntax quotation such as
```
`(let x := %%a;
  ite x x %%b)
```
We will parse this quotation, and during elaboration, we must create
code (i.e., an `Expr`) such that given `a` and `b`, it constructs
a (new) syntax object, and we want to guarantee that there is no accidental name capture.
So, given the syntax object `S` representing the quotation above, we
first pre-resolve the identifiers in `S`. In this step, we annotate the
identifier `ite` with the global declaration `_root_.ite`.
Then, we create a fresh identifier for each identifier, but we would
preserve the pre-resolved information.
Assume the monadic action `mkFresh <id>` creates a fresh identifier with
prefix `<id>`, and `mkFreshWithPreresolved <id> <pre-list>` creates a
fresh identifier with prefix <id> and pre-resolved list `<pre-list>`.
Then, the quotation above would be transformed into:
```
let x := mkFresh `x;
let ite := mkFreshWith `ite [`_root_.ite];
`(let %%x := %%a;
 %%ite %%x %%x %%b)
```
Here, the new quotation is just syntax sugar for a sequence of `Syntax`
constructor applications. Now, whenever we want to create a syntax
object using the quotation above, we guarantee there is no accidental
name capture because we are creating a fresh identifier for all
identifiers in the quotation. Global references are preserved using the
field preresolved that we already have.
It is straightforward to implement the transformation above using a
mapping. Note that if we use the same mapping to elaborate two different
quotations, we are essentially saying they share the same scope.
For example, suppose we have
```
let c := `(ite x x %%b);
`(let x := %%a; %%c)
```
If we use the same mapping, we produce
```
let x := mkFresh `x;
let ite := mkFreshWith `ite [`_root_.ite];
let c := `(%%ite %%x %%x %%b);
`(let %%x := %%a; %%c)
```
If we create a new mapping when compiling each quotation, we get
```
let x := mkFresh `x;
let ite := mkFreshWith `ite [`_root_.ite];
let c := `(%%ite %%x %%x %%b);
let x1 := mkFresh `x;
`(let %%x1 := %%a; %%c)
```
which is probably not what the user wants.
We can provide a simple notation for users specifying which behavior
they want. The default may be super simple. Example: we have a new mapping (aka scope) per declaration.
The approach above is simple and efficient. It is also great for
users that want to create syntax objects during the elaboration phase
and want to avoid name capture.
2019-07-15 10:00:27 -07:00
Leonardo de Moura
113ab4824f feat(library/init/lean/syntax): add Syntax.getTailInfo 2019-07-05 16:21:51 -07:00
Leonardo de Moura
dca0ba60fa feat(library/init/lean/parser/parser): add fieldIdx parser
We should not use `numLit` for projections since it will parse
`p.1.2` as
```
Term.proj `p (numLit "1.2")
```
2019-07-05 15:07:51 -07:00
Leonardo de Moura
3285a9e77d chore(library/init): unnecessary parentheses 2019-07-05 13:23:19 -07:00
Leonardo de Moura
ea6eee516b chore(frontends/lean): use => instead of := in match-expressions
Motivation: use same separator used in lambda expressions as in
other programming languages.
2019-07-04 11:38:38 -07:00
Leonardo de Moura
a02443d23d chore(frontends/lean): fun x, e ==> fun x => e 2019-07-02 13:22:11 -07:00
Leonardo de Moura
91e1d30cf8 feat(frontends/lean/builtin_exprs): use ; in do-notation 2019-06-27 18:00:43 -07:00
Leonardo de Moura
ab487ea4ac feat(frontends/lean): allow ; instead of in in let-decls 2019-06-27 17:12:03 -07:00
Leonardo de Moura
e00dc873a8 chore(library/pattern_attribute): [pattern] ==> [matchPattern] 2019-06-26 11:26:49 -07:00
Leonardo de Moura
c7597b8975 fix(library/init/lean/syntax): typo at isNatLit 2019-06-26 10:48:47 -07:00
Leonardo de Moura
aa111df0ec feat(library/init/lean/syntax): add Syntax.isIdOrAtom 2019-06-25 11:20:31 -07:00
Leonardo de Moura
2e01ac508a feat(library/init/lean/syntax): primitives for creating and testing string and nat literals 2019-06-25 10:39:23 -07:00
Leonardo de Moura
af2d6dbd45 chore(library/init): avoid local attribute 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
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
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
280e7bb006 feat(library/init/lean/attributes): add TagAttributes
`TagAttribute`s are implemented on top of the low level Attribute API,
and `PersistentEnvExtension`.
This is just the first attribute on a series of attributes we are
going to implement using Lean itself.
2019-06-05 21:54:28 -07:00
Leonardo de Moura
d212abb9ee feat(library/init/lean/syntax): export helper functions for creating syntax in C++ 2019-06-05 16:49:58 -07:00
Leonardo de Moura
7909d86e5d feat(library/init/lean): Syntax objects with new SyntaxNodeKind and Substring, and arrays instead of lists
We can use `SyntaxNodeKind.id : Nat` to implement maps from kind to
values using arrays.
2019-06-05 15:35:51 -07:00