Zulip Chat Archive
Stream: general
Topic: quotient type woes
Kevin Buzzard (May 18 2018 at 22:20):
I find myself finally having to engage with the quotient type.
Kevin Buzzard (May 18 2018 at 22:22):
I am in the middle of a definition of "add" for a quotient type and I find myself with a proof that contains a line (sorry)
Kevin Buzzard (May 18 2018 at 22:22):
and if I replace that line with (begin sorry end)
Kevin Buzzard (May 18 2018 at 22:22):
then suddenly the proof stops type checking.
Kevin Buzzard (May 18 2018 at 22:22):
How can that happen?
Kenny Lau (May 18 2018 at 22:22):
because you want begin admit end
Kevin Buzzard (May 18 2018 at 22:23):
sorry
works now!
Kevin Buzzard (May 18 2018 at 22:24):
it's a recent change
Kevin Buzzard (May 18 2018 at 22:24):
Same problem with admit
Kevin Buzzard (May 18 2018 at 22:28):
https://github.com/kbuzzard/lean-stacks-project/blob/master/src/tag007N.lean
Kevin Buzzard (May 18 2018 at 22:28):
In our project @Kenny Lau
Kevin Buzzard (May 18 2018 at 22:28):
How many exams left by the way?
Kenny Lau (May 18 2018 at 22:29):
3
Kevin Buzzard (May 18 2018 at 22:29):
Mon Wed Fri next week?
Kenny Lau (May 18 2018 at 22:29):
tue wed fri
Kevin Buzzard (May 18 2018 at 22:29):
And Chris the same
Kenny Lau (May 18 2018 at 22:29):
right
Kevin Buzzard (May 18 2018 at 22:29):
I can't wait until Friday, I have to learn quotient types!
Kenny Lau (May 18 2018 at 22:30):
well...
Kevin Buzzard (May 18 2018 at 22:30):
It's about time I learnt them.
Kevin Buzzard (May 18 2018 at 22:30):
After all, I am supposed to have taught them to 267 students this year
Kevin Buzzard (May 18 2018 at 23:06):
If you replace (sorry)
with ({sorry})
you get a different error :-)
Kevin Buzzard (May 18 2018 at 23:06):
type mismatch at application quotient.lift ?m_4 {sorry} term {sorry} has type ?m_1 : Type ? but is expected to have type ∀ (a b : ?m_1), a ≈ b → ?m_4 a = ?m_4 b : Prop Additional information: /home/buzzard/lean-projects/lean-stacks-project/src/tag007N.lean:21:21: context: 'eliminator' elaboration is not used for 'quotient.lift' because resulting type is not of the expected form state: X : Type u, _inst_1 : topological_space X, B : set (set X), HB : topological_space.is_topological_basis B, FPRB : presheaf_of_rings_on_basis HB, x : X, Hstandard : ∀ (U V : set X), U ∈ B → V ∈ B → U ∩ V ∈ B ⊢ aux (FPRB.to_presheaf_of_types_on_basis) x → stalk FPRB x → stalk FPRB x
Kevin Buzzard (May 18 2018 at 23:07):
'eliminator' elaboration is not used for 'quotient.lift' because resulting type is not of the expected form
Kevin Buzzard (May 18 2018 at 23:07):
I'd never seen that one until today and now I've seen it a lot :-/
Kevin Buzzard (May 18 2018 at 23:08):
It must change the order things are elaborated?
Kevin Buzzard (May 18 2018 at 23:08):
There is more than one sorry in this definition
Kevin Buzzard (May 18 2018 at 23:13):
(deleted)
Kevin Buzzard (May 18 2018 at 23:14):
(deleted)
Kevin Buzzard (May 18 2018 at 23:16):
So by sorry
is also an error (the same error)
Mario Carneiro (May 19 2018 at 01:17):
I think this is a "dependent sorry" issue, similar to one that came up earlier with sorry in structure fields. If you write quotient.lift _ sorry
, then the sorry has a metavariable type and this is not allowed (gives an error at the sorry application). Whereas if you write quotient.lift sorry sorry
then the metavariable is replaced with sorry
which is an actual term, so it should work. (You can still get these kinds of errors if you put too many sorries around because this can cause implicit variables that are normally solved by unification fail to be resolved because of sorry
's unhelpful type.)
Mario Carneiro (May 19 2018 at 01:23):
And quotient.lift (by admit) sorry
causes the same error since the tactic causes a delay in elaboration of the first sorry, so it tries to make sense of quotient.lift _ sorry
first before getting to the tactic, and this is what causes the error.
Kevin Buzzard (May 19 2018 at 13:53):
init_quotient: initialize quotient type computational rules
Kevin Buzzard (May 19 2018 at 13:53):
Just found that with #help commands
Kevin Buzzard (May 19 2018 at 13:53):
What does that do?
Kenny Lau (May 19 2018 at 13:54):
that gives you the quot.lift
axioms etc
Kenny Lau (May 19 2018 at 13:54):
it appears in core
Kevin Buzzard (May 19 2018 at 13:54):
documentation for that command is better than for coinductive:
Kevin Buzzard (May 19 2018 at 13:54):
coinductive: description
Kevin Buzzard (May 19 2018 at 13:55):
Oh I see -- so I don't really need to run init_quotient
myself?
Kenny Lau (May 19 2018 at 13:55):
no, you don't
Kevin Buzzard (May 19 2018 at 13:57):
Anyway, my next quotient type woe is that if I have an object defined as a quotient type and I want to put, say, a group structure on it, then my definition of the multiplication should presumably be done in term mode and should avoid idioms such as \lam \<U,BU,Hx,s\>
Kevin Buzzard (May 19 2018 at 13:57):
which makes the code look horrible.
Kevin Buzzard (May 19 2018 at 13:58):
Is there any way around this? I tried writing a definition of a ring structure on a stalk of a sheaf of rings and the moment I started using \lam \<U,BU,...\>
I ran into what I think are standard issues of things not being refl because they are something._match1.something
or something
Mario Carneiro (May 19 2018 at 14:02):
use projections instead of a lambda match
Kevin Buzzard (May 19 2018 at 14:11):
Right, so \lam X
and then X.U
, X.BU
etc.
Kevin Buzzard (May 19 2018 at 14:13):
I am a bit surprised that Lean won't do something this simple internally. Presumably what's going on is that the matching machinery is sophisticated and does not guarantee unravelling to something simple even if ultimately I am doing nothing more than a simple match on the components of a structure.
Last updated: Dec 20 2023 at 11:08 UTC