Commit graph

21229 commits

Author SHA1 Message Date
Leonardo de Moura
149f69ad8f chore: update stage0 2020-09-24 12:47:48 -07:00
Leonardo de Moura
8383177c96 fix: nonoptimal specialization
@Kha Here is the fix for the problem I told you this morning.
Please, take a look at `specialize.cpp` and see whether it makes sense.
2020-09-24 12:40:28 -07:00
Leonardo de Moura
550b5d2b47 chore: missing [inline] 2020-09-24 12:40:28 -07:00
Sebastian Ullrich
f73fca1da7 chore: make_stdlib: use everything but lean from the current stage
Finally the stage 1 stdlib will be built against the headers in src/, not stage0/src/
2020-09-24 18:57:53 +02:00
Sebastian Ullrich
c0d40c6f86 chore: always use release build for stage 0 2020-09-24 18:57:53 +02:00
Sebastian Ullrich
c54d51b0c9 chore: go back to previous bootstrapping scheme where the stage N+1 stdlib is created using the stage N compiler 2020-09-24 18:57:53 +02:00
Sebastian Ullrich
308b4fc421 chore: always remake leanmake tests 2020-09-24 18:57:53 +02:00
Leonardo de Moura
6fe8a0e179 test: issue 29
New frontend fixed this issue.
closes #29
2020-09-23 18:30:28 -07:00
Leonardo de Moura
e22d2f6cb1 test: new tests for structural recursion
@Kha The structural recursion is working :)
It is so much more powerful than the one in Lean3.
I added examples with `let rec`, nested and multiple
`match`-expressions.
I will keep testing and adding missing features tomorrow, and
will hopefully start porting stdlib to new frontend before the end of
the week.
2020-09-23 18:24:56 -07:00
Leonardo de Moura
6a51ec8427 fix: missing case (kernel projection) at isExprDefEqAuxImpl 2020-09-23 18:24:56 -07:00
Leonardo de Moura
a5ee729554 chore: cleanup ExprDefEq a bit 2020-09-23 18:24:56 -07:00
Leonardo de Moura
6ac2f50d94 fix: Expr.proj case at whnfCoreImp 2020-09-23 18:24:56 -07:00
Leonardo de Moura
3c24366b41 feat: basic toBelow 2020-09-23 18:24:56 -07:00
Leonardo de Moura
0174004b1c feat: improver error message generation for termination checking 2020-09-23 18:24:56 -07:00
Leonardo de Moura
bd01093388 feat: add Meta.forEachExpr 2020-09-23 18:24:56 -07:00
Leonardo de Moura
44eee0c3a4 feat: improve replaceRecApps 2020-09-23 18:24:56 -07:00
Leonardo de Moura
c46e64b089 feat: add Array.zipWith and Array.zip 2020-09-23 18:24:56 -07:00
Sebastian Ullrich
fa55c1e088 fix: pretty printing loose bvars
Fixes #192
2020-09-23 11:13:23 +02:00
Leonardo de Moura
d66b6738ee chore: fix test 2020-09-22 19:07:46 -07:00
Leonardo de Moura
8135d37ddb feat: add MatcherApp.addArg
Helper method for adding a new (dependent) argument to a (dependent) matcher.
2020-09-22 18:56:02 -07:00
Leonardo de Moura
3586337c56 perf: handle easy case efficiently 2020-09-22 18:55:13 -07:00
Leonardo de Moura
661548a2fe refactor: move mkArrow to MetaM 2020-09-22 18:55:02 -07:00
Leonardo de Moura
1256fc3cbc refactor: move MatcherInfo methods to Meta namespace 2020-09-22 16:59:21 -07:00
Leonardo de Moura
8a920f7aeb feat: replaceRecApps find matcher 2020-09-22 16:55:15 -07:00
Leonardo de Moura
a397b3d2ae feat: add matchMatcherApp? 2020-09-22 16:54:54 -07:00
Leonardo de Moura
41e6447837 refactor: use MetaM and exceptions 2020-09-22 16:05:28 -07:00
Leonardo de Moura
25bcc95b13 feat: construct brecOn application
TODO: replace recursive application with `below` argument
2020-09-22 14:39:22 -07:00
Leonardo de Moura
0511b73d80 feat: add replaceFVars 2020-09-22 14:24:03 -07:00
Leonardo de Moura
bbc1f4d461 fix: throwAppTypeMismatch should be polymorphic
We use it from `TermElabM` and `MetaM`, and they have different
`TermElabM` implementations.
2020-09-22 09:35:59 -07:00
Leonardo de Moura
05e5d934d3 feat: change default precedence for new syntax
Now, the following example produces a syntax error.
```lean
macro "foo!" x:term : term => `($x + 1)

check id foo! 10
```

@Kha, I think the heuristic is simple and defensible.
If the new syntax starts and ends with token, than the precedence is
`maxPrec`. Otherwise, it is `leadPrec`.

see #180
2020-09-21 19:04:03 -07:00
Leonardo de Moura
dc9626ceab feat: try to improve weird error message
@Kha Before this commit, we were producing the error "expected command" at the `let` token
```lean
check id let x := 1; x
```
The new error is "expected command, but found term; this error may be
due to parsing precedence levels, consider parenthesizing the term".

The example above looks artificial, but it will happen all the time as
users start to define their own notation.
2020-09-21 18:29:01 -07:00
Leonardo de Moura
1b358967ba chore: update stage0 2020-09-21 17:13:42 -07:00
Leonardo de Moura
f4b5ec710f fix: fixes #175 2020-09-21 17:12:07 -07:00
Leonardo de Moura
b0564a32b9 feat: add AttrM
We are going to use `AttrM` to implement solution 2 described at https://github.com/leanprover/lean4/issues/175
2020-09-21 16:44:20 -07:00
Leonardo de Moura
cab56d1e1b chore: do not invoke the hooks from addImported
@Kha I am working on issue
https://github.com/leanprover/lean4/issues/175

I am using solution 2 described there. The hooks will be at `AttrM`
instead of `CoreM`.

AFAICT code deleted by this commit is not necessary.
2020-09-21 16:28:07 -07:00
Leonardo de Moura
c19814a624 chore: avoid memory leak
@Kha I suspect the memory leaks reported at the CI are due to
an exception produced by the compiler.
The compiler is currently a mix of Lean and C++ code.
I think the exception was thrown from C++ code, crossed Lean code (producing
memory leaks), and was caught by the old frontend written in C++.

We will eventually replace the compiler C++ code with Lean code.
So, I think this is a low priority issue.
2020-09-21 13:30:58 -07:00
Leonardo de Moura
38df6de545 chore: update stage0 2020-09-21 12:28:20 -07:00
Leonardo de Moura
151e877513 refactor: seal EnvExtension type
The motivation is to prevent users from tinkering with its internal
implementation details that rely on unsafe features.
The new test crashed before this commit.
2020-09-21 12:24:44 -07:00
Leonardo de Moura
1f9f12975c chore: seal EnvExtensionState and EnvExtensionEntry 2020-09-21 11:48:57 -07:00
Leonardo de Moura
c9e902034d fix: typo 2020-09-21 11:44:26 -07:00
Leonardo de Moura
0de92b069f chore: move function 2020-09-21 08:58:41 -07:00
Leonardo de Moura
aa6d6c4dda feat: expose mkModuleInitializationFunctionName
cc @Kha

for https://github.com/leanprover/lean4/issues/185
2020-09-21 08:53:29 -07:00
Leonardo de Moura
30a1e0228b chore: add where to list of keywords 2020-09-21 08:27:29 -07:00
Sebastian Ullrich
f693e910b1 fix: skip minimum amount of tokens during parser recovery
Fixes #186
2020-09-21 11:37:50 +02:00
Leonardo de Moura
6a90fbf855 test: String interpolation
@Kha I wrote this extended test using the new frontend. The new
frontend worked great. I only had a minor issue with `#exit`.
The example uses `let rec`, parsers, macros, lift-method notation, etc.
It implements the new parser `strInterpolant p` for string
interpolation. The parser `p` is used to process the elements inside
`{...}`. Then, I use this parser to implement the macro `toString!`.
Example: `toString! "1+2 = {1+2}"` produces `"1+2 = 3"`.
Even the new "lift-method" notation works inside the string interpolant.
```lean
def g (x : Nat) : StateRefT Nat IO Nat := do
modify (· + x);
get

def ex : StateRefT Nat IO Unit := do
IO.println $ toString! ">> hello {(<- g 1)}";
IO.println $ toString! ">> world {(<- g 1)}";
pure ()
```
2020-09-20 18:11:19 -07:00
Leonardo de Moura
9eb978946c chore: add quotedCharCoreFn 2020-09-20 17:05:47 -07:00
Leonardo de Moura
241eabfc41 fix: non termination on ill-formed string literals 2020-09-20 17:05:18 -07:00
Leonardo de Moura
03a361edf4 feat: add initialize command parser 2020-09-20 13:42:50 -07:00
Leonardo de Moura
13abf0bd45 chore: update stage0 2020-09-20 09:17:12 -07:00
Leonardo de Moura
d33f7c7885 feat: attribute command 2020-09-20 09:11:36 -07:00