michael/lean2
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions
lean2/tests/lean/tst6.lean.expected.out

119 lines
4.1 KiB
Text
Raw Normal View History

Modify verbose message for Set command Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-02 19:29:21 +00:00
Set: pp::colors
Fix unit tests for Windows Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-03 17:44:51 +00:00
Set: pp::unicode
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
Assumed: N
Assumed: h
Proved: CongrH
Modify verbose message for Set command Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-02 19:29:21 +00:00
Set: lean::pp::implicit
feat(frontends/lean): hide 'explicit' version of objects with implicit arguments Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-19 21:12:39 +00:00
Variable h : N → N → N
refactor(equality): make homogeneous equality the default equality It was not a good idea to use heterogeneous equality as the default equality in Lean. It creates the following problems. - Heterogeneous equality does not propagate constraints in the elaborator. For example, suppose that l has type (List Int), then the expression l = nil will not propagate the type (List Int) to nil. - It is easy to write false. For example, suppose x has type Real, and the user writes x = 0. This is equivalent to false, since 0 has type Nat. The elaborator cannot introduce the coercion since x = 0 is a type correct expression. Homogeneous equality does not suffer from the problems above. We keep heterogeneous equality because it is useful for generating proof terms. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-29 23:20:02 +00:00
Theorem CongrH {a1 a2 b1 b2 : N} (H1 : eq::explicit N a1 b1) (H2 : eq::explicit N a2 b2) : eq::explicit
N
(h a1 a2)
(h b1 b2) :=
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
Congr::explicit
N
Minimize use the colors in tests. The colors make the diff hard to read Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 17:34:57 +00:00
(λ x : N, N)
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
(h a1)
(h b1)
a2
b2
Minimize use the colors in tests. The colors make the diff hard to read Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 17:34:57 +00:00
(Congr::explicit N (λ x : N, N → N) h h a1 b1 (Refl::explicit (N → N → N) h) H1)
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
H2
Modify verbose message for Set command Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-02 19:29:21 +00:00
Set: lean::pp::implicit
feat(frontends/lean): hide 'explicit' version of objects with implicit arguments Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-19 21:12:39 +00:00
Variable h : N → N → N
fix(frontends/lean/pp): make sure pp and parser are using the same precedences Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-19 20:46:14 +00:00
Theorem CongrH {a1 a2 b1 b2 : N} (H1 : a1 = b1) (H2 : a2 = b2) : h a1 a2 = h b1 b2 := Congr (Congr (Refl h) H1) H2
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
Proved: Example1
Modify verbose message for Set command Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-02 19:29:21 +00:00
Set: lean::pp::implicit
refactor(equality): make homogeneous equality the default equality It was not a good idea to use heterogeneous equality as the default equality in Lean. It creates the following problems. - Heterogeneous equality does not propagate constraints in the elaborator. For example, suppose that l has type (List Int), then the expression l = nil will not propagate the type (List Int) to nil. - It is easy to write false. For example, suppose x has type Real, and the user writes x = 0. This is equivalent to false, since 0 has type Nat. The elaborator cannot introduce the coercion since x = 0 is a type correct expression. Homogeneous equality does not suffer from the problems above. We keep heterogeneous equality because it is useful for generating proof terms. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-29 23:20:02 +00:00
Theorem Example1 (a b c d : N)
(H : eq::explicit N a b ∧ eq::explicit N b c ∨ eq::explicit N a d ∧ eq::explicit N d c) : eq::explicit
N
(h a b)
(h c b) :=
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
DisjCases::explicit
refactor(equality): make homogeneous equality the default equality It was not a good idea to use heterogeneous equality as the default equality in Lean. It creates the following problems. - Heterogeneous equality does not propagate constraints in the elaborator. For example, suppose that l has type (List Int), then the expression l = nil will not propagate the type (List Int) to nil. - It is easy to write false. For example, suppose x has type Real, and the user writes x = 0. This is equivalent to false, since 0 has type Nat. The elaborator cannot introduce the coercion since x = 0 is a type correct expression. Homogeneous equality does not suffer from the problems above. We keep heterogeneous equality because it is useful for generating proof terms. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-29 23:20:02 +00:00
(eq::explicit N a b ∧ eq::explicit N b c)
(eq::explicit N a d ∧ eq::explicit N d c)
fix(frontends/lean/pp): make sure pp and parser are using the same precedences Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-19 20:46:14 +00:00
(h a b == h c b)
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
H
refactor(equality): make homogeneous equality the default equality It was not a good idea to use heterogeneous equality as the default equality in Lean. It creates the following problems. - Heterogeneous equality does not propagate constraints in the elaborator. For example, suppose that l has type (List Int), then the expression l = nil will not propagate the type (List Int) to nil. - It is easy to write false. For example, suppose x has type Real, and the user writes x = 0. This is equivalent to false, since 0 has type Nat. The elaborator cannot introduce the coercion since x = 0 is a type correct expression. Homogeneous equality does not suffer from the problems above. We keep heterogeneous equality because it is useful for generating proof terms. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-29 23:20:02 +00:00
(λ H1 : eq::explicit N a b ∧ eq::explicit N b c,
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
CongrH::explicit
a
b
c
b
(Trans::explicit
N
a
b
c
refactor(equality): make homogeneous equality the default equality It was not a good idea to use heterogeneous equality as the default equality in Lean. It creates the following problems. - Heterogeneous equality does not propagate constraints in the elaborator. For example, suppose that l has type (List Int), then the expression l = nil will not propagate the type (List Int) to nil. - It is easy to write false. For example, suppose x has type Real, and the user writes x = 0. This is equivalent to false, since 0 has type Nat. The elaborator cannot introduce the coercion since x = 0 is a type correct expression. Homogeneous equality does not suffer from the problems above. We keep heterogeneous equality because it is useful for generating proof terms. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-29 23:20:02 +00:00
(Conjunct1::explicit (eq::explicit N a b) (eq::explicit N b c) H1)
(Conjunct2::explicit (eq::explicit N a b) (eq::explicit N b c) H1))
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
(Refl::explicit N b))
refactor(equality): make homogeneous equality the default equality It was not a good idea to use heterogeneous equality as the default equality in Lean. It creates the following problems. - Heterogeneous equality does not propagate constraints in the elaborator. For example, suppose that l has type (List Int), then the expression l = nil will not propagate the type (List Int) to nil. - It is easy to write false. For example, suppose x has type Real, and the user writes x = 0. This is equivalent to false, since 0 has type Nat. The elaborator cannot introduce the coercion since x = 0 is a type correct expression. Homogeneous equality does not suffer from the problems above. We keep heterogeneous equality because it is useful for generating proof terms. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-29 23:20:02 +00:00
(λ H1 : eq::explicit N a d ∧ eq::explicit N d c,
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
CongrH::explicit
a
b
c
b
(Trans::explicit
N
a
d
c
refactor(equality): make homogeneous equality the default equality It was not a good idea to use heterogeneous equality as the default equality in Lean. It creates the following problems. - Heterogeneous equality does not propagate constraints in the elaborator. For example, suppose that l has type (List Int), then the expression l = nil will not propagate the type (List Int) to nil. - It is easy to write false. For example, suppose x has type Real, and the user writes x = 0. This is equivalent to false, since 0 has type Nat. The elaborator cannot introduce the coercion since x = 0 is a type correct expression. Homogeneous equality does not suffer from the problems above. We keep heterogeneous equality because it is useful for generating proof terms. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-29 23:20:02 +00:00
(Conjunct1::explicit (eq::explicit N a d) (eq::explicit N d c) H1)
(Conjunct2::explicit (eq::explicit N a d) (eq::explicit N d c) H1))
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
(Refl::explicit N b))
Proved: Example2
Modify verbose message for Set command Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-02 19:29:21 +00:00
Set: lean::pp::implicit
refactor(equality): make homogeneous equality the default equality It was not a good idea to use heterogeneous equality as the default equality in Lean. It creates the following problems. - Heterogeneous equality does not propagate constraints in the elaborator. For example, suppose that l has type (List Int), then the expression l = nil will not propagate the type (List Int) to nil. - It is easy to write false. For example, suppose x has type Real, and the user writes x = 0. This is equivalent to false, since 0 has type Nat. The elaborator cannot introduce the coercion since x = 0 is a type correct expression. Homogeneous equality does not suffer from the problems above. We keep heterogeneous equality because it is useful for generating proof terms. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-29 23:20:02 +00:00
Theorem Example2 (a b c d : N)
(H : eq::explicit N a b ∧ eq::explicit N b c ∨ eq::explicit N a d ∧ eq::explicit N d c) : eq::explicit
N
(h a b)
(h c b) :=
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
DisjCases::explicit
refactor(equality): make homogeneous equality the default equality It was not a good idea to use heterogeneous equality as the default equality in Lean. It creates the following problems. - Heterogeneous equality does not propagate constraints in the elaborator. For example, suppose that l has type (List Int), then the expression l = nil will not propagate the type (List Int) to nil. - It is easy to write false. For example, suppose x has type Real, and the user writes x = 0. This is equivalent to false, since 0 has type Nat. The elaborator cannot introduce the coercion since x = 0 is a type correct expression. Homogeneous equality does not suffer from the problems above. We keep heterogeneous equality because it is useful for generating proof terms. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-29 23:20:02 +00:00
(eq::explicit N a b ∧ eq::explicit N b c)
(eq::explicit N a d ∧ eq::explicit N d c)
feat(library/elaborator): modify how elaborator handles constraints of the form ?M << P and P << ?M, where P is a proposition. Before this commit, the elaborator would only assign ?M <- P, if P was normalized. This is bad since normalization may "destroy" the structure of P. For example, consider the constraint [a : Bool; b : Bool; c : Bool] ⊢ ?M::1 ≺ implies a (implies b (and a b)) Before this, ?M::1 will not be assigned to the "implies-term" because the "implies-term" is not normalized yet. So, the elaborator would continue to process the constraint, and convert it into: [a : Bool; b : Bool; c : Bool] ⊢ ?M::1 ≺ if Bool a (if Bool b (if Bool (if Bool a (if Bool b false true) true) false true) true) true Now, ?M::1 is assigned to the term if Bool a (if Bool b (if Bool (if Bool a (if Bool b false true) true) false true) true) true This is bad, since the original structure was lost. This commit also contains an example that only works after the commit is applied. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-11-29 17:14:54 +00:00
(eq::explicit N (h a b) (h c b))
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
H
refactor(equality): make homogeneous equality the default equality It was not a good idea to use heterogeneous equality as the default equality in Lean. It creates the following problems. - Heterogeneous equality does not propagate constraints in the elaborator. For example, suppose that l has type (List Int), then the expression l = nil will not propagate the type (List Int) to nil. - It is easy to write false. For example, suppose x has type Real, and the user writes x = 0. This is equivalent to false, since 0 has type Nat. The elaborator cannot introduce the coercion since x = 0 is a type correct expression. Homogeneous equality does not suffer from the problems above. We keep heterogeneous equality because it is useful for generating proof terms. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-29 23:20:02 +00:00
(λ H1 : eq::explicit N a b ∧ eq::explicit N b c,
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
CongrH::explicit
a
b
c
b
(Trans::explicit
N
a
b
c
feat(library/elaborator): only expand definitions that are not marked as hidden The elaborator produces better proof terms. This is particularly important when we have to prove the remaining holes using tactics. For example, in one of the tests, the elaborator was producing the sub-expression (λ x : N, if ((λ x::1 : N, if (P a x x::1) ⊥ ⊤) == (λ x : N, ⊤)) ⊥ ⊤) After, this commit it produces (λ x : N, ¬ ∀ x::1 : N, ¬ P a x x::1) The expressions above are definitionally equal, but the second is easier to work with. Question: do we really need hidden definitions? Perhaps, we can use only the opaque flag. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-20 10:16:41 +00:00
(Conjunct1::explicit (a == b) (eq::explicit N b c) H1)
(Conjunct2::explicit (eq::explicit N a b) (b == c) H1))
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
(Refl::explicit N b))
refactor(equality): make homogeneous equality the default equality It was not a good idea to use heterogeneous equality as the default equality in Lean. It creates the following problems. - Heterogeneous equality does not propagate constraints in the elaborator. For example, suppose that l has type (List Int), then the expression l = nil will not propagate the type (List Int) to nil. - It is easy to write false. For example, suppose x has type Real, and the user writes x = 0. This is equivalent to false, since 0 has type Nat. The elaborator cannot introduce the coercion since x = 0 is a type correct expression. Homogeneous equality does not suffer from the problems above. We keep heterogeneous equality because it is useful for generating proof terms. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-29 23:20:02 +00:00
(λ H1 : eq::explicit N a d ∧ eq::explicit N d c,
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
CongrH::explicit
a
b
c
b
(Trans::explicit
N
a
d
c
feat(library/elaborator): only expand definitions that are not marked as hidden The elaborator produces better proof terms. This is particularly important when we have to prove the remaining holes using tactics. For example, in one of the tests, the elaborator was producing the sub-expression (λ x : N, if ((λ x::1 : N, if (P a x x::1) ⊥ ⊤) == (λ x : N, ⊤)) ⊥ ⊤) After, this commit it produces (λ x : N, ¬ ∀ x::1 : N, ¬ P a x x::1) The expressions above are definitionally equal, but the second is easier to work with. Question: do we really need hidden definitions? Perhaps, we can use only the opaque flag. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-20 10:16:41 +00:00
(Conjunct1::explicit (a == d) (eq::explicit N d c) H1)
(Conjunct2::explicit (eq::explicit N a d) (d == c) H1))
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
(Refl::explicit N b))
Proved: Example3
Modify verbose message for Set command Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-02 19:29:21 +00:00
Set: lean::pp::implicit
fix(frontends/lean/pp): make sure pp and parser are using the same precedences Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-19 20:46:14 +00:00
Theorem Example3 (a b c d e : N) (H : a = b ∧ b = e ∧ b = c ∨ a = d ∧ d = c) : h a b = h c b :=
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
DisjCases
H
Minimize use the colors in tests. The colors make the diff hard to read Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 17:34:57 +00:00
(λ H1 : a = b ∧ b = e ∧ b = c, CongrH (Trans (Conjunct1 H1) (Conjunct2 (Conjunct2 H1))) (Refl b))
(λ H1 : a = d ∧ d = c, CongrH (Trans (Conjunct1 H1) (Conjunct2 H1)) (Refl b))
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
Proved: Example4
Modify verbose message for Set command Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-02 19:29:21 +00:00
Set: lean::pp::implicit
fix(frontends/lean/pp): make sure pp and parser are using the same precedences Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-19 20:46:14 +00:00
Theorem Example4 (a b c d e : N) (H : a = b ∧ b = e ∧ b = c ∨ a = d ∧ d = c) : h a c = h c a :=
Move files in examples directory to tests directory. They are not real examples Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 02:15:48 +00:00
DisjCases
H
Minimize use the colors in tests. The colors make the diff hard to read Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-01 17:34:57 +00:00
(λ H1 : a = b ∧ b = e ∧ b = c,
let AeqC := Trans (Conjunct1 H1) (Conjunct2 (Conjunct2 H1)) in CongrH AeqC (Symm AeqC))
(λ H1 : a = d ∧ d = c, let AeqC := Trans (Conjunct1 H1) (Conjunct2 H1) in CongrH AeqC (Symm AeqC))
Reference in a new issue Copy permalink