docs: document defeq and type inference related functions - #2
Open
rish987 wants to merge 7 commits into
Open
Conversation
digama0
reviewed
May 18, 2024
digama0
reviewed
May 18, 2024
| pure e | ||
| else | ||
| let r := f.mkAppRevRange 0 rargs.size rargs | ||
| -- FIXME replace with reduceRecursor? adding arguments can only result in further normalization if the head reduced to a partial recursor application |
Owner
There was a problem hiding this comment.
Couldn't it also reduce to a lambda?
Contributor
Author
There was a problem hiding this comment.
Yes, but in that case it would have went into the first branch of the conditional.
rish987
changed the title
digama0
reviewed
Jul 11, 2024
digama0
added a commit
that referenced
this pull request
Aug 4, 2026
* docs: document defeq and type inference related functions Squash merge of PR #2 by rish987. Reference: #2 Adds documentation for defeq and type-inference related functions to improve codebase understandability. * docs: restyle to match the codebase Reflow the docstrings added in the previous commit to the style used in the rest of the codebase: text starts on the `/--` line, `-/` closes the last line, and lines are wrapped at 100 columns (also applied to the new `--` comments, four of which ran to 100-187 columns). Incidental fixes while rewrapping: backtick and modernize the `cheapBetaReduce` example (Lean 3 `λ x, x` -> `fun x => x`, and the body is `xᵢ`, not `x₁`); `inferConstant` documents `.const name ls`, not `.const e ls`; `->` -> `→` and `cheapProj = true` -> `cheapProj := true`. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> * docs: correct the claims that don't match the code The docstrings added two commits ago were written against an older lean4lean and describe several things the code does not do. Rewritten against the current implementation: * `unfoldDefinitionCore` takes a `.const`, not an application with a constant head (that is `unfoldDefinition`); its doc had been copied from `isDelta`. * `isDelta` also requires the right number of universe levels, and the question of which constants delta-reduce is already settled by `ConstantInfo.deltaValue?`, so point at it rather than restating it. * `quickIsDefEq` defers constants and free variables too, not just applications and projections, and it refutes as well as confirms. Same correction in the `lazyDeltaReductionStep` and `lazyDeltaReduction` docs, which reused the wording. * `lazyDeltaReductionStep` hands `.unknown` back to `isDefEqCore'`, not `isDefEq`. * `reduceNat` was missing `Nat.succ`, `land`, `lor`, `xor`, `shiftLeft` and `shiftRight`, and `Nat.beq`/`Nat.ble` yield `Bool`, not `Nat`, literals. * `isDefEqOffset` decides `0 ≡ 0` before looking at successors. * `cheapBetaReduce` also reduces a body with no loose bvars, and leaves `e` alone in every other case, which is the point of the name. * `toCtorWhenStruct`'s `String` example predates `String` becoming a two-field structure over `ByteArray`; use `Prod`. Likewise `tryStringLitExpansionCore` matches `String.ofList`, which is no longer the constructor. * `inductiveReduceRec` applies the rule to the motives and minor premises as well as the parameters, accepts literal major premises, and re-applies the arguments past the major premise. * `inferType` also throws on resource exhaustion, so not "if and only if". * `isDefEqCore` referred to a `check` function; it is `checkType`. * `whnfFVar` uses `whnfCore`, and `whnfCore`'s `cheapRec` is never set. * `RecM.run` and `lazyDeltaReduction` take their limits from `FuelConfig`. All three `FIXME(kernel)` comments are rewritten as statements: each asked a question the code answers -- `cheapProj := true` leaves head projections unreduced, the recursive `whnfCore` call does reach `reduceRecursor`, and the eta-struct case is redundant work that the kernel performs identically -- so none of them is a divergence, and none stays a FIXME. Co-authored-by: Mario Carneiro <marioc@chalmers.se> Co-authored-by: Claude Opus 5 <noreply@anthropic.com> Co-authored-by: Rishikesh Vaishnav <rishhvaishnav@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Hi, I've been adding some documentation while trying to understand this implementation better. Regarding the FIXMEs, I've left them in for now just because I was curious if you have any thoughts on them (I think I will also do a bit of experimentation regarding them), but I can remove them before merging. I plan to add some docs for the type-inference functions next.