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

116 lines
4.8 KiB
Text
Raw Normal View History

Create pp::unicode option. The idea is to be able to disable unicode characters, but still be able to use mixfix notation. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-03 17:09:19 +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
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
Failed to solve
refactor(kernel/metavar): avoid using unique names for default metavariable prefix The problem is that unique names depend on the order compilation units are initialized. The order of initialization is not specified by the C++ standard. Then, different compilers (or even the same compiler) may produce different initialization orders, and consequently the metavariable prefix is going to be different for different builds. This is not a bug, but it makes unit tests to fail since the output produced by different builds is different for the same input file. Avoiding unique name feature in the default metavariable prefix avoids this problem. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-11-07 18:16:22 +00:00
⊢ (?M::0 ≈ Nat::add) ⊕ (?M::0 ≈ Int::add) ⊕ (?M::0 ≈ Real::add)
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
(line: 1: pos: 10) Overloading at
(Real::add | Int::add | Nat::add) 1 ⊤
Failed to solve
⊢ Bool ≺ ℕ
Substitution
refactor(kernel/metavar): avoid using unique names for default metavariable prefix The problem is that unique names depend on the order compilation units are initialized. The order of initialization is not specified by the C++ standard. Then, different compilers (or even the same compiler) may produce different initialization orders, and consequently the metavariable prefix is going to be different for different builds. This is not a bug, but it makes unit tests to fail since the output produced by different builds is different for the same input file. Avoiding unique name feature in the default metavariable prefix avoids this problem. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-11-07 18:16:22 +00:00
⊢ Bool ≺ ?M::8
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
(line: 1: pos: 10) Type of argument 2 must be convertible to the expected type in the application of
refactor(kernel/metavar): avoid using unique names for default metavariable prefix The problem is that unique names depend on the order compilation units are initialized. The order of initialization is not specified by the C++ standard. Then, different compilers (or even the same compiler) may produce different initialization orders, and consequently the metavariable prefix is going to be different for different builds. This is not a bug, but it makes unit tests to fail since the output produced by different builds is different for the same input file. Avoiding unique name feature in the default metavariable prefix avoids this problem. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-11-07 18:16:22 +00:00
?M::0
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
with arguments:
refactor(kernel/metavar): avoid using unique names for default metavariable prefix The problem is that unique names depend on the order compilation units are initialized. The order of initialization is not specified by the C++ standard. Then, different compilers (or even the same compiler) may produce different initialization orders, and consequently the metavariable prefix is going to be different for different builds. This is not a bug, but it makes unit tests to fail since the output produced by different builds is different for the same input file. Avoiding unique name feature in the default metavariable prefix avoids this problem. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-11-07 18:16:22 +00:00
?M::1 1
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
⊤
Assignment
refactor(kernel/metavar): avoid using unique names for default metavariable prefix The problem is that unique names depend on the order compilation units are initialized. The order of initialization is not specified by the C++ standard. Then, different compilers (or even the same compiler) may produce different initialization orders, and consequently the metavariable prefix is going to be different for different builds. This is not a bug, but it makes unit tests to fail since the output produced by different builds is different for the same input file. Avoiding unique name feature in the default metavariable prefix avoids this problem. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-11-07 18:16:22 +00:00
⊢ ℕ ≈ ?M::8
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
Destruct/Decompose
feat(kernel/metavar): make sure that a metavariable 'm' can only be assigned to a term that contains free variables available in the context associated with 'm' This commit also simplifies the method check_pi in the type_checker and type_inferer. It also fixes process_meta_app in the elaborator. The problem was in the method process_meta_app and process_meta_inst. They were processing convertability constrains as equality constraints. For example, process_meta_app would handle ctx |- Type << ?f b as ctx |- Type =:= ?f b This is not correct because a ?f that returns (Type U) for b satisfies the first but not the second. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-14 20:25:00 +00:00
⊢ ℕ → ℕ ≈ Π x : ?M::8, ?M::9
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
Substitution
feat(kernel/metavar): make sure that a metavariable 'm' can only be assigned to a term that contains free variables available in the context associated with 'm' This commit also simplifies the method check_pi in the type_checker and type_inferer. It also fixes process_meta_app in the elaborator. The problem was in the method process_meta_app and process_meta_inst. They were processing convertability constrains as equality constraints. For example, process_meta_app would handle ctx |- Type << ?f b as ctx |- Type =:= ?f b This is not correct because a ?f that returns (Type U) for b satisfies the first but not the second. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-14 20:25:00 +00:00
⊢ ?M::7[inst:0 (?M::1 1)] ≈ Π x : ?M::8, ?M::9
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
(line: 1: pos: 10) Function expected at
refactor(kernel/metavar): avoid using unique names for default metavariable prefix The problem is that unique names depend on the order compilation units are initialized. The order of initialization is not specified by the C++ standard. Then, different compilers (or even the same compiler) may produce different initialization orders, and consequently the metavariable prefix is going to be different for different builds. This is not a bug, but it makes unit tests to fail since the output produced by different builds is different for the same input file. Avoiding unique name feature in the default metavariable prefix avoids this problem. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-11-07 18:16:22 +00:00
?M::0 (?M::1 1) ⊤
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
Assignment
feat(kernel/metavar): make sure that a metavariable 'm' can only be assigned to a term that contains free variables available in the context associated with 'm' This commit also simplifies the method check_pi in the type_checker and type_inferer. It also fixes process_meta_app in the elaborator. The problem was in the method process_meta_app and process_meta_inst. They were processing convertability constrains as equality constraints. For example, process_meta_app would handle ctx |- Type << ?f b as ctx |- Type =:= ?f b This is not correct because a ?f that returns (Type U) for b satisfies the first but not the second. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-14 20:25:00 +00:00
_ : ℕ ⊢ ℕ → ℕ ≈ ?M::7
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
Destruct/Decompose
feat(kernel/metavar): make sure that a metavariable 'm' can only be assigned to a term that contains free variables available in the context associated with 'm' This commit also simplifies the method check_pi in the type_checker and type_inferer. It also fixes process_meta_app in the elaborator. The problem was in the method process_meta_app and process_meta_inst. They were processing convertability constrains as equality constraints. For example, process_meta_app would handle ctx |- Type << ?f b as ctx |- Type =:= ?f b This is not correct because a ?f that returns (Type U) for b satisfies the first but not the second. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-14 20:25:00 +00:00
⊢ ℕ → ℕ → ℕ ≈ Π x : ?M::6, ?M::7
Substitution
⊢ ?M::2 ≈ Π x : ?M::6, ?M::7
(line: 1: pos: 10) Function expected at
?M::0 (?M::1 1) ⊤
Assignment
⊢ ℕ → ℕ → ℕ ≺ ?M::2
Propagate type, ?M::0 : ?M::2
Assignment
⊢ ?M::0 ≈ Nat::add
Assumption 0
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
Failed to solve
⊢ Bool ≺ ℤ
Substitution
refactor(kernel/metavar): avoid using unique names for default metavariable prefix The problem is that unique names depend on the order compilation units are initialized. The order of initialization is not specified by the C++ standard. Then, different compilers (or even the same compiler) may produce different initialization orders, and consequently the metavariable prefix is going to be different for different builds. This is not a bug, but it makes unit tests to fail since the output produced by different builds is different for the same input file. Avoiding unique name feature in the default metavariable prefix avoids this problem. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-11-07 18:16:22 +00:00
⊢ Bool ≺ ?M::8
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
(line: 1: pos: 10) Type of argument 2 must be convertible to the expected type in the application of
refactor(kernel/metavar): avoid using unique names for default metavariable prefix The problem is that unique names depend on the order compilation units are initialized. The order of initialization is not specified by the C++ standard. Then, different compilers (or even the same compiler) may produce different initialization orders, and consequently the metavariable prefix is going to be different for different builds. This is not a bug, but it makes unit tests to fail since the output produced by different builds is different for the same input file. Avoiding unique name feature in the default metavariable prefix avoids this problem. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-11-07 18:16:22 +00:00
?M::0
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
with arguments:
refactor(kernel/metavar): avoid using unique names for default metavariable prefix The problem is that unique names depend on the order compilation units are initialized. The order of initialization is not specified by the C++ standard. Then, different compilers (or even the same compiler) may produce different initialization orders, and consequently the metavariable prefix is going to be different for different builds. This is not a bug, but it makes unit tests to fail since the output produced by different builds is different for the same input file. Avoiding unique name feature in the default metavariable prefix avoids this problem. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-11-07 18:16:22 +00:00
?M::1 1
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
⊤
Assignment
refactor(kernel/metavar): avoid using unique names for default metavariable prefix The problem is that unique names depend on the order compilation units are initialized. The order of initialization is not specified by the C++ standard. Then, different compilers (or even the same compiler) may produce different initialization orders, and consequently the metavariable prefix is going to be different for different builds. This is not a bug, but it makes unit tests to fail since the output produced by different builds is different for the same input file. Avoiding unique name feature in the default metavariable prefix avoids this problem. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-11-07 18:16:22 +00:00
⊢ ℤ ≈ ?M::8
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
Destruct/Decompose
feat(kernel/metavar): make sure that a metavariable 'm' can only be assigned to a term that contains free variables available in the context associated with 'm' This commit also simplifies the method check_pi in the type_checker and type_inferer. It also fixes process_meta_app in the elaborator. The problem was in the method process_meta_app and process_meta_inst. They were processing convertability constrains as equality constraints. For example, process_meta_app would handle ctx |- Type << ?f b as ctx |- Type =:= ?f b This is not correct because a ?f that returns (Type U) for b satisfies the first but not the second. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-14 20:25:00 +00:00
⊢ ℤ → ℤ ≈ Π x : ?M::8, ?M::9
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
Substitution
feat(kernel/metavar): make sure that a metavariable 'm' can only be assigned to a term that contains free variables available in the context associated with 'm' This commit also simplifies the method check_pi in the type_checker and type_inferer. It also fixes process_meta_app in the elaborator. The problem was in the method process_meta_app and process_meta_inst. They were processing convertability constrains as equality constraints. For example, process_meta_app would handle ctx |- Type << ?f b as ctx |- Type =:= ?f b This is not correct because a ?f that returns (Type U) for b satisfies the first but not the second. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-14 20:25:00 +00:00
⊢ ?M::7[inst:0 (?M::1 1)] ≈ Π x : ?M::8, ?M::9
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
(line: 1: pos: 10) Function expected at
refactor(kernel/metavar): avoid using unique names for default metavariable prefix The problem is that unique names depend on the order compilation units are initialized. The order of initialization is not specified by the C++ standard. Then, different compilers (or even the same compiler) may produce different initialization orders, and consequently the metavariable prefix is going to be different for different builds. This is not a bug, but it makes unit tests to fail since the output produced by different builds is different for the same input file. Avoiding unique name feature in the default metavariable prefix avoids this problem. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-11-07 18:16:22 +00:00
?M::0 (?M::1 1) ⊤
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
Assignment
feat(kernel/metavar): make sure that a metavariable 'm' can only be assigned to a term that contains free variables available in the context associated with 'm' This commit also simplifies the method check_pi in the type_checker and type_inferer. It also fixes process_meta_app in the elaborator. The problem was in the method process_meta_app and process_meta_inst. They were processing convertability constrains as equality constraints. For example, process_meta_app would handle ctx |- Type << ?f b as ctx |- Type =:= ?f b This is not correct because a ?f that returns (Type U) for b satisfies the first but not the second. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-14 20:25:00 +00:00
_ : ℤ ⊢ ℤ → ℤ ≈ ?M::7
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
Destruct/Decompose
feat(kernel/metavar): make sure that a metavariable 'm' can only be assigned to a term that contains free variables available in the context associated with 'm' This commit also simplifies the method check_pi in the type_checker and type_inferer. It also fixes process_meta_app in the elaborator. The problem was in the method process_meta_app and process_meta_inst. They were processing convertability constrains as equality constraints. For example, process_meta_app would handle ctx |- Type << ?f b as ctx |- Type =:= ?f b This is not correct because a ?f that returns (Type U) for b satisfies the first but not the second. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-14 20:25:00 +00:00
⊢ ℤ → ℤ → ℤ ≈ Π x : ?M::6, ?M::7
Substitution
⊢ ?M::2 ≈ Π x : ?M::6, ?M::7
(line: 1: pos: 10) Function expected at
?M::0 (?M::1 1) ⊤
Assignment
⊢ ℤ → ℤ → ℤ ≺ ?M::2
Propagate type, ?M::0 : ?M::2
Assignment
⊢ ?M::0 ≈ Int::add
Assumption 2
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
Failed to solve
⊢ Bool ≺ ℝ
Substitution
refactor(kernel/metavar): avoid using unique names for default metavariable prefix The problem is that unique names depend on the order compilation units are initialized. The order of initialization is not specified by the C++ standard. Then, different compilers (or even the same compiler) may produce different initialization orders, and consequently the metavariable prefix is going to be different for different builds. This is not a bug, but it makes unit tests to fail since the output produced by different builds is different for the same input file. Avoiding unique name feature in the default metavariable prefix avoids this problem. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-11-07 18:16:22 +00:00
⊢ Bool ≺ ?M::8
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
(line: 1: pos: 10) Type of argument 2 must be convertible to the expected type in the application of
refactor(kernel/metavar): avoid using unique names for default metavariable prefix The problem is that unique names depend on the order compilation units are initialized. The order of initialization is not specified by the C++ standard. Then, different compilers (or even the same compiler) may produce different initialization orders, and consequently the metavariable prefix is going to be different for different builds. This is not a bug, but it makes unit tests to fail since the output produced by different builds is different for the same input file. Avoiding unique name feature in the default metavariable prefix avoids this problem. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-11-07 18:16:22 +00:00
?M::0
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
with arguments:
refactor(kernel/metavar): avoid using unique names for default metavariable prefix The problem is that unique names depend on the order compilation units are initialized. The order of initialization is not specified by the C++ standard. Then, different compilers (or even the same compiler) may produce different initialization orders, and consequently the metavariable prefix is going to be different for different builds. This is not a bug, but it makes unit tests to fail since the output produced by different builds is different for the same input file. Avoiding unique name feature in the default metavariable prefix avoids this problem. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-11-07 18:16:22 +00:00
?M::1 1
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
⊤
Assignment
refactor(kernel/metavar): avoid using unique names for default metavariable prefix The problem is that unique names depend on the order compilation units are initialized. The order of initialization is not specified by the C++ standard. Then, different compilers (or even the same compiler) may produce different initialization orders, and consequently the metavariable prefix is going to be different for different builds. This is not a bug, but it makes unit tests to fail since the output produced by different builds is different for the same input file. Avoiding unique name feature in the default metavariable prefix avoids this problem. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-11-07 18:16:22 +00:00
⊢ ℝ ≈ ?M::8
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
Destruct/Decompose
feat(kernel/metavar): make sure that a metavariable 'm' can only be assigned to a term that contains free variables available in the context associated with 'm' This commit also simplifies the method check_pi in the type_checker and type_inferer. It also fixes process_meta_app in the elaborator. The problem was in the method process_meta_app and process_meta_inst. They were processing convertability constrains as equality constraints. For example, process_meta_app would handle ctx |- Type << ?f b as ctx |- Type =:= ?f b This is not correct because a ?f that returns (Type U) for b satisfies the first but not the second. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-14 20:25:00 +00:00
⊢ ℝ → ℝ ≈ Π x : ?M::8, ?M::9
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
Substitution
feat(kernel/metavar): make sure that a metavariable 'm' can only be assigned to a term that contains free variables available in the context associated with 'm' This commit also simplifies the method check_pi in the type_checker and type_inferer. It also fixes process_meta_app in the elaborator. The problem was in the method process_meta_app and process_meta_inst. They were processing convertability constrains as equality constraints. For example, process_meta_app would handle ctx |- Type << ?f b as ctx |- Type =:= ?f b This is not correct because a ?f that returns (Type U) for b satisfies the first but not the second. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-14 20:25:00 +00:00
⊢ ?M::7[inst:0 (?M::1 1)] ≈ Π x : ?M::8, ?M::9
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
(line: 1: pos: 10) Function expected at
refactor(kernel/metavar): avoid using unique names for default metavariable prefix The problem is that unique names depend on the order compilation units are initialized. The order of initialization is not specified by the C++ standard. Then, different compilers (or even the same compiler) may produce different initialization orders, and consequently the metavariable prefix is going to be different for different builds. This is not a bug, but it makes unit tests to fail since the output produced by different builds is different for the same input file. Avoiding unique name feature in the default metavariable prefix avoids this problem. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-11-07 18:16:22 +00:00
?M::0 (?M::1 1) ⊤
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
Assignment
feat(kernel/metavar): make sure that a metavariable 'm' can only be assigned to a term that contains free variables available in the context associated with 'm' This commit also simplifies the method check_pi in the type_checker and type_inferer. It also fixes process_meta_app in the elaborator. The problem was in the method process_meta_app and process_meta_inst. They were processing convertability constrains as equality constraints. For example, process_meta_app would handle ctx |- Type << ?f b as ctx |- Type =:= ?f b This is not correct because a ?f that returns (Type U) for b satisfies the first but not the second. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-14 20:25:00 +00:00
_ : ℝ ⊢ ℝ → ℝ ≈ ?M::7
fix(tests/lean): adjust error messages in the expected output Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-25 02:08:35 +00:00
Destruct/Decompose
feat(kernel/metavar): make sure that a metavariable 'm' can only be assigned to a term that contains free variables available in the context associated with 'm' This commit also simplifies the method check_pi in the type_checker and type_inferer. It also fixes process_meta_app in the elaborator. The problem was in the method process_meta_app and process_meta_inst. They were processing convertability constrains as equality constraints. For example, process_meta_app would handle ctx |- Type << ?f b as ctx |- Type =:= ?f b This is not correct because a ?f that returns (Type U) for b satisfies the first but not the second. Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-12-14 20:25:00 +00:00
⊢ ℝ → ℝ → ℝ ≈ Π x : ?M::6, ?M::7
Substitution
⊢ ?M::2 ≈ Π x : ?M::6, ?M::7
(line: 1: pos: 10) Function expected at
?M::0 (?M::1 1) ⊤
Assignment
⊢ ℝ → ℝ → ℝ ≺ ?M::2
Propagate type, ?M::0 : ?M::2
Assignment
⊢ ?M::0 ≈ Real::add
Assumption 5
Improve error messages when overloads+coercions do not work Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-09-03 03:05:47 +00:00
Assumed: R
Assumed: T
Assumed: r2t
Coercion r2t
Assumed: t2r
Coercion t2r
Assumed: f
Assumed: a
Assumed: b
Set: lean::pp::coercion
Set: lean::pp::notation
f a b
f (r2t b) (t2r a)
Assumed: g
f a b
fix(frontends/lean/elaborator): fix bugs and adjust tests Signed-off-by: Leonardo de Moura <leonardo@microsoft.com>
2013-10-24 22:29:56 +00:00
f (r2t b) (t2r a)
Reference in a new issue Copy permalink