Skip to content

tutorial: projecting out of a structure that may or may not be a Prop - #153

Merged
nomeata merged 1 commit into
masterfrom
joachim/proj-of-maybe-prop
Aug 22, 2026
Merged

tutorial: projecting out of a structure that may or may not be a Prop#153
nomeata merged 1 commit into
masterfrom
joachim/proj-of-maybe-prop

Conversation

@nomeata

@nomeata nomeata commented Aug 22, 2026

Copy link
Copy Markdown
Collaborator

MaybeProp.{u} : Sort u is a proposition exactly for u := 0. Lean's
inductive command refuses such a declaration, but the kernel accepts it,
and projecting out of it is fine at every instantiation: a structure that
is not a Prop had every constructor field's universe checked against its
resulting universe, and that inequality survives instantiation, so wherever
the structure does become a proposition all of its fields do too.

That argument turns on the two checks agreeing on what a proposition is.
Waiving the field universe bound at declaration time and forbidding data
projections are two halves of one rule: a kernel generous about "is this a
Prop?" when declaring the inductive and strict about it when checking a
projection puts a data field inside a proposition, and proof irrelevance
collapses it into a proof of False. Erring the other way is safe but
incomplete, and that is what these tests catch — asking "could this be a
Prop?" and then demanding the field be definitely a proof rejects a
legitimate declaration. projMaybeProp catches that at the field being
asked for, projMaybePropPast on the way past a preceding one, which is a
separate code path.

The shape is not exotic: a dependent pair kept at the exact maximum of its
components lands in Sort (max u v), which poses the same question, and
this is why PProd and PSigma use Sort (max 1 u v) instead.

Co-Authored-By: Claude Fable 5 noreply@anthropic.com
Claude-Session: https://claude.ai/code/session_01UakEtNJTcwyaEtfLhR8BLn

`MaybeProp.{u} : Sort u` is a proposition exactly for `u := 0`. Lean's
`inductive` command refuses such a declaration, but the kernel accepts it,
and projecting out of it is fine at every instantiation: a structure that
is not a `Prop` had every constructor field's universe checked against its
resulting universe, and that inequality survives instantiation, so wherever
the structure does become a proposition all of its fields do too.

That argument turns on the two checks agreeing on what a proposition is.
Waiving the field universe bound at declaration time and forbidding data
projections are two halves of one rule: a kernel generous about "is this a
`Prop`?" when declaring the inductive and strict about it when checking a
projection puts a data field inside a proposition, and proof irrelevance
collapses it into a proof of `False`. Erring the other way is safe but
incomplete, and that is what these tests catch — asking "could this be a
`Prop`?" and then demanding the field be definitely a proof rejects a
legitimate declaration. `projMaybeProp` catches that at the field being
asked for, `projMaybePropPast` on the way past a preceding one, which is a
separate code path.

The shape is not exotic: a dependent pair kept at the exact maximum of its
components lands in `Sort (max u v)`, which poses the same question, and
this is why `PProd` and `PSigma` use `Sort (max 1 u v)` instead.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UakEtNJTcwyaEtfLhR8BLn
@nomeata
nomeata merged commit 4641477 into master Aug 22, 2026
24 checks passed
@nomeata
nomeata deleted the joachim/proj-of-maybe-prop branch August 22, 2026 09:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant