Zulip Chat Archive
Stream: lean4
Topic: variable {C}
Kevin Buzzard (Jun 17 2021 at 18:54):
Here's a change from Lean 3:
variable (C : Type) [Inhabited C]
example : C := arbitrary
variable {C}
example : C := arbitrary -- fails
/-
failed to synthesize instance
Inhabited C
-/
If I change the default binder for C
then I lose the type class [Inhabited C]
. Is this expected behaviour?
[Back story: I'm manually porting some category theory to Lean 4 and initially I thought we were back in the 2019 hell of having to include 𝒞
when universes got hairy, made even worse here by the fact that include
might not have made it to Lean 4 yet (?). I then realised that in fact
something far simpler was going on :D . In fact Lean 4 universes seem to be working fine in category theory so far.]
Marc Huisinga (Jun 17 2021 at 18:58):
You didn't really change the default binder, you declared a new C
, right?
E.g. in the first example C : Type
and in the second one C : Sort u
.
Daniel Selsam (Jun 17 2021 at 19:01):
FYI this was added to Lean3 @ https://github.com/leanprover-community/lean/commit/dc93603b4af3f0ed4559d48fe3d55e4e68ffbdfb
Kevin Buzzard (Jun 17 2021 at 19:11):
@Marc Huisinga this is my point -- in Lean 3 this works fine
variables (C : Type) [inhabited C]
example : C := arbitrary C
variable {C}
example : C := arbitrary C
and this idiom is used quite a bit in mathlib -- you develop some theory about groups with (G : Type*) [group G]
and then you want to develop some stuff involving (g : G)
so you write variable {G}
and now G
is still a group but it's implicit in the lemmas where it's included from that point on. So I thought I did change the default binder. I don't understand Daniel's link -- C or C++ or whatever it is is all greek to me.
Daniel Selsam (Jun 17 2021 at 19:17):
Kevin Buzzard said:
I don't understand Daniel's link -- C or C++ or whatever it is is all greek to me. Update: aah! I understand the tests though :-)
Sorry for the curt response above :) -- In addition to the tests, the commit message links to the original GitHub issue that motivated the feature (https://github.com/leanprover/lean/issues/532).
Daniel Selsam (Jun 17 2021 at 19:22):
I recommend creating a Lean4 issue for the feature.
Kevin Buzzard (Jun 17 2021 at 19:37):
Daniel Selsam (Jun 17 2021 at 19:38):
Does anyone else find that this topic keeps getting removed from the #lean4
stream list? It looks like a bug in Zulip, probably triggered by the braces in the topic name.
Daniel Selsam (Jun 17 2021 at 19:42):
Kevin Buzzard said:
Note: the syntax highlighting isn't working in your issue for some reason.
Marc Huisinga (Jun 17 2021 at 19:43):
Kevin Buzzard said:
Marc Huisinga this is my point -- in Lean 3 this works fine
Ah, sorry :) I wasn't sure if you had already noticed that it's unrelated to the type class.
Kevin Buzzard (Jun 17 2021 at 22:44):
Another weird thing: I _did_ click on the "#532" link on github (the one which Daniel pointed out in his second post), but when I did it, it took me to https://github.com/leanprover-community/lean/pull/532 (the fork) which is unrelated, and this was what caused my "I don't understand anything" outburst.
Kevin Buzzard (Jun 17 2021 at 22:55):
Daniel Selsam said:
Kevin Buzzard said:
Note: the syntax highlighting isn't working in your issue for some reason.
On Zulip ```
is enough, but on github I need ```lean
. I fixed it.
Daniel Selsam (Jun 18 2021 at 01:33):
Kevin Buzzard said:
Another weird thing: I _did_ click on the "#532" link on github (the one which Daniel pointed out in his second post), but when I did it, it took me to https://github.com/leanprover-community/lean/pull/532 (the fork) which is unrelated, and this was what caused my "I don't understand anything" outburst.
That was my fault -- I should have originally linked to the commit from the leanprover
repo instead of the leanprover-community
repo so that the issue link would work.
Last updated: Dec 20 2023 at 11:08 UTC