File: .lake/packages/lean4/src/lean/Lean/Parser/Term.lean

full_name: Lean.Parser.Command.commentBody
code: def commentBody : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Command.commentBody.parenthesizer
code: @[combinator_parenthesizer commentBody]
def commentBody.parenthesizer 
goal: Lean.PrettyPrinter.Parenthesizer

full_name: Lean.Parser.Command.commentBody.formatter
code: @[combinator_formatter commentBody]
def commentBody.formatter 
goal: Lean.PrettyPrinter.Formatter

full_name: Lean.Parser.Command.docComment
code: /-- A `docComment` parses a "documentation comment" like `/-- foo -/`. This is not treated like
a regular comment (that is, as whitespace); it is parsed and forms part of the syntax tree structure.

A `docComment` node contains a `/--` atom and then the remainder of the comment, `foo -/` in this
example. Use `TSyntax.getDocString` to extract the body text from a doc string syntax node. -/
def docComment 
goal: Lean.Parser.Parser

full_name: Lean.Parser.initFn._@..lake.packages.lean4.src.lean.Lean.Parser.Term._hyg.72
code: builtin_initialize
  registerBuiltinParserAttribute `builtin_tactic_parser ``Category.tactic .both
  registerBuiltinDynamicParserAttribute `tactic_parser `tactic
goal: IO Unit

full_name: Lean.Parser.tacticParser
code: @[inline] def tacticParser (rbp : Nat := 0) : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.convParser
code: @[inline] def convParser (rbp : Nat := 0) : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Tactic.sepByIndentSemicolon
code: /-- `sepByIndentSemicolon(p)` parses a sequence of `p` optionally followed by `;`,
similar to `manyIndent(p ";"?)`, except that if two occurrences of `p` occur on the same line,
the `;` is mandatory. This is used by tactic parsing, so that
```
example := by
  skip
  skip
```
is legal, but `by skip skip` is not - it must be written as `by skip; skip`. -/
@[run_builtin_parser_attribute_hooks]
def sepByIndentSemicolon (p : Parser) : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Tactic.sepBy1IndentSemicolon
code: /-- `sepBy1IndentSemicolon(p)` parses a (nonempty) sequence of `p` optionally followed by `;`,
similar to `many1Indent(p ";"?)`, except that if two occurrences of `p` occur on the same line,
the `;` is mandatory. This is used by tactic parsing, so that
```
example := by
  skip
  skip
```
is legal, but `by skip skip` is not - it must be written as `by skip; skip`. -/
@[run_builtin_parser_attribute_hooks]
def sepBy1IndentSemicolon (p : Parser) : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Tactic.initFn._@..lake.packages.lean4.src.lean.Lean.Parser.Term._hyg.209
code: builtin_initialize
  register_parser_alias sepByIndentSemicolon
  register_parser_alias sepBy1IndentSemicolon
goal: IO Unit

full_name: Lean.Parser.Tactic.tacticSeq1Indented
code: def tacticSeq1Indented : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Tactic.tacticSeqBracketed
code: /-- The syntax `{ tacs }` is an alternative syntax for `· tacs`.
It runs the tactics in sequence, and fails if the goal is not solved. -/
def tacticSeqBracketed : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Tactic.tacticSeq
code: /-- A sequence of tactics in brackets, or a delimiter-free indented sequence of tactics.
Delimiter-free indentation is determined by the *first* tactic of the sequence. -/
def tacticSeq 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Tactic.tacticSeqIndentGt
code: /-- Same as [`tacticSeq`] but requires delimiter-free tactic sequence to have strict indentation.
The strict indentation requirement only apply to *nested* `by`s, as top-level `by`s do not have a
position set. -/
def tacticSeqIndentGt 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Tactic.seq1
code: def seq1 
goal: Lean.Parser.Parser

full_name: Lean.Parser.darrow
code: def darrow : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.semicolonOrLinebreak
code: def semicolonOrLinebreak 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.byTactic
code: /-- `by tac` constructs a term of the expected type by running the tactic(s) `tac`. -/
@[builtin_term_parser] def byTactic 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.byTactic'
code: def byTactic' 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.optSemicolon
code: def optSemicolon (p : Parser) : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.ident
code: @[builtin_term_parser] def ident 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.num
code: @[builtin_term_parser] def num : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.scientific
code: @[builtin_term_parser] def scientific : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.str
code: @[builtin_term_parser] def str : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.char
code: @[builtin_term_parser] def char : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.type
code: /-- A type universe. `Type ≡ Type 0`, `Type u ≡ Sort (u + 1)`. -/
@[builtin_term_parser] def type 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.sort
code: /-- A specific universe in Lean's infinite hierarchy of universes. -/
@[builtin_term_parser] def sort 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.prop
code: /-- The universe of propositions. `Prop ≡ Sort 0`. -/
@[builtin_term_parser] def prop 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.hole
code: /-- A placeholder term, to be synthesized by unification. -/
@[builtin_term_parser] def hole 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.syntheticHole
code: /-- Parses a "synthetic hole", that is, `?foo` or `?_`.
This syntax is used to construct named metavariables. -/
@[builtin_term_parser] def syntheticHole 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.omission
code: /--
The `⋯` term denotes a term that was omitted by the pretty printer.
The presence of `⋯` in pretty printer output is controlled by the `pp.deepTerms` and `pp.proofs` options,
and these options can be further adjusted using `pp.deepTerms.threshold` and `pp.proofs.threshold`.

It is only meant to be used for pretty printing.
However, in case it is copied and pasted from the Infoview, `⋯` logs a warning and elaborates like `_`.
-/
@[builtin_term_parser] def omission 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.binderIdent
code: def binderIdent : Parser  
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.sorry
code: /-- A temporary placeholder for a missing proof or value. -/
@[builtin_term_parser] def «sorry» 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.cdot
code: /--
A placeholder for an implicit lambda abstraction's variable. The lambda abstraction is scoped to the surrounding parentheses.
For example, `(· + ·)` is equivalent to `fun x y => x + y`.
-/
@[builtin_term_parser] def cdot   
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.typeAscription
code: /--
Type ascription notation: `(0 : Int)` instructs Lean to process `0` as a value of type `Int`.
An empty type ascription `(e :)` elaborates `e` without the expected type.
This is occasionally useful when Lean's heuristics for filling arguments from the expected type
do not yield the right result.
-/
@[builtin_term_parser] def typeAscription 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.tuple
code: /-- Tuple notation; `()` is short for `Unit.unit`, `(a, b, c)` for `Prod.mk a (Prod.mk b c)`, etc. -/
@[builtin_term_parser] def tuple 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.paren
code: /--
Parentheses, used for grouping expressions (e.g., `a * (b + c)`).
Can also be used for creating simple functions when combined with `·`. Here are some examples:
  - `(· + 1)` is shorthand for `fun x => x + 1`
  - `(· + ·)` is shorthand for `fun x y => x + y`
  - `(f · a b)` is shorthand for `fun x => f x a b`
  - `(h (· + 1) ·)` is shorthand for `fun x => h (fun y => y + 1) x`
  - also applies to other parentheses-like notations such as `(·, 1)`
-/
@[builtin_term_parser] def paren 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.anonymousCtor
code: /--
The *anonymous constructor* `⟨e, ...⟩` is equivalent to `c e ...` if the
expected type is an inductive type with a single constructor `c`.
If more terms are given than `c` has parameters, the remaining arguments
are turned into a new anonymous constructor application. For example,
`⟨a, b, c⟩ : α × (β × γ)` is equivalent to `⟨a, ⟨b, c⟩⟩`.
-/
@[builtin_term_parser] def anonymousCtor 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.optIdent
code: def optIdent : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.fromTerm
code: def fromTerm   
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.showRhs
code: def showRhs 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.sufficesDecl
code: /-- A `sufficesDecl` represents everything that comes after the `suffices` keyword:
an optional `x :`, then a term `ty`, then `from val` or `by tac`. -/
def sufficesDecl 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.suffices
code: @[builtin_term_parser] def «suffices» 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.show
code: @[builtin_term_parser] def «show»     
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.structInstArrayRef
code: def structInstArrayRef 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.structInstLVal
code: def structInstLVal   
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.structInstField
code: def structInstField  
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.structInstFieldAbbrev
code: def structInstFieldAbbrev 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.optEllipsis
code: def optEllipsis      
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.structInst
code: /--
Structure instance. `{ x := e, ... }` assigns `e` to field `x`, which may be
inherited. If `e` is itself a variable called `x`, it can be elided:
`fun y => { x := 1, y }`.
A *structure update* of an existing value can be given via `with`:
`{ point with x := 1 }`.
The structure type can be specified if not inferable:
`{ x := 1, y := 2 : Point }`.
-/
@[builtin_term_parser] def structInst 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.typeSpec
code: def typeSpec 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.optType
code: def optType : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.explicit
code: /--
`@x` disables automatic insertion of implicit parameters of the constant `x`.
`@e` for any term `e` also disables the insertion of implicit lambdas at this position.
-/
@[builtin_term_parser] def explicit 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.inaccessible
code: /--
`.(e)` marks an "inaccessible pattern", which does not influence evaluation of the pattern match, but may be necessary for type-checking.
In contrast to regular patterns, `e` may be an arbitrary term of the appropriate type.
-/
@[builtin_term_parser] def inaccessible 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.binderType
code: def binderType (requireType := false) : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.binderTactic
code: def binderTactic  
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.binderDefault
code: def binderDefault 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.binderDefault.parenthesizer
code: @[combinator_parenthesizer Lean.Parser.Term.binderDefault] def binderDefault.parenthesizer : Parenthesizer 
goal: Lean.PrettyPrinter.Parenthesizer

full_name: Lean.Parser.Term.explicitBinder
code: /--
Explicit binder, like `(x y : A)` or `(x y)`.
Default values can be specified using `(x : A := v)` syntax, and tactics using `(x : A := by tac)`.
-/
def explicitBinder (requireType := false) 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.implicitBinder
code: /--
Implicit binder, like `{x y : A}` or `{x y}`.
In regular applications, whenever all parameters before it have been specified,
then a `_` placeholder is automatically inserted for this parameter.
Implicit parameters should be able to be determined from the other arguments and the return type
by unification.

In `@` explicit mode, implicit binders behave like explicit binders.
-/
def implicitBinder (requireType := false) 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.strictImplicitLeftBracket
code: def strictImplicitLeftBracket 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.strictImplicitRightBracket
code: def strictImplicitRightBracket 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.strictImplicitBinder
code: /--
Strict-implicit binder, like `⦃x y : A⦄` or `⦃x y⦄`.
In contrast to `{ ... }` implicit binders, strict-implicit binders do not automatically insert
a `_` placeholder until at least one subsequent explicit parameter is specified.
Do *not* use strict-implicit binders unless there is a subsequent explicit parameter.
Assuming this rule is followed, for fully applied expressions implicit and strict-implicit binders have the same behavior.

Example: If `h : ∀ ⦃x : A⦄, x ∈ s → p x` and `hs : y ∈ s`,
then `h` by itself elaborates to itself without inserting `_` for the `x : A` parameter,
and `h hs` has type `p y`.
In contrast, if `h' : ∀ {x : A}, x ∈ s → p x`, then `h` by itself elaborates to have type `?m ∈ s → p ?m`
with `?m` a fresh metavariable.
-/
def strictImplicitBinder (requireType := false) 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.instBinder
code: /--
Instance-implicit binder, like `[C]` or `[inst : C]`.
In regular applications without `@` explicit mode, it is automatically inserted
and solved for by typeclass inference for the specified class `C`.
In `@` explicit mode, if `_` is used for an an instance-implicit parameter, then it is still solved for by typeclass inference;
use `(_)` to inhibit this and have it be solved for by unification instead, like an implicit argument.
-/
def instBinder 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.bracketedBinder
code: /-- A `bracketedBinder` matches any kind of binder group that uses some kind of brackets:
* An explicit binder like `(x y : A)`
* An implicit binder like `{x y : A}`
* A strict implicit binder, `⦃y z : A⦄` or its ASCII alternative `{{y z : A}}`
* An instance binder `[A]` or `[x : A]` (multiple variables are not allowed here)
-/
def bracketedBinder (requireType := false) 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.depArrow
code: @[builtin_term_parser] def depArrow 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.forall
code: @[builtin_term_parser]
def «forall» 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.matchAlt
code: def matchAlt (rhsParser : Parser := termParser) : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.matchAltExpr
code: /--
  Useful for syntax quotations. Note that generic patterns such as `` `(matchAltExpr| | ... => $rhs) `` should also
  work with other `rhsParser`s (of arity 1). -/
def matchAltExpr 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.«instCoeTSyntaxConsSyntaxNodeKindMkStr4Nil_.lake»
code: instance : Coe (TSyntax ``matchAltExpr) (TSyntax ``matchAlt) 
goal: Coe (Lean.TSyntax `Lean.Parser.Term.matchAltExpr) (Lean.TSyntax `Lean.Parser.Term.matchAlt)

full_name: Lean.Parser.Term.matchAlts
code: def matchAlts (rhsParser : Parser := termParser) : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.matchDiscr
code: /-- `matchDiscr` matches a "match discriminant", either `h : tm` or `tm`, used in `match` as
`match h1 : e1, e2, h3 : e3 with ...`. -/
def matchDiscr 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.trueVal
code: def trueVal  
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.falseVal
code: def falseVal 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.generalizingParam
code: def generalizingParam 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.motive
code: def motive 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.match
code: /--
Pattern matching. `match e, ... with | p, ... => f | ...` matches each given
term `e` against each pattern `p` of a match alternative. When all patterns
of an alternative match, the `match` term evaluates to the value of the
corresponding right-hand side `f` with the pattern variables bound to the
respective matched values.
If used as `match h : e, ... with | p, ... => f | ...`, `h : e = p` is available
within `f`.

When not constructing a proof, `match` does not automatically substitute variables
matched on in dependent variables' types. Use `match (generalizing := true) ...` to
enforce this.

Syntax quotations can also be used in a pattern match.
This matches a `Syntax` value against quotations, pattern variables, or `_`.

Quoted identifiers only match identical identifiers - custom matching such as by the preresolved
names only should be done explicitly.

`Syntax.atom`s are ignored during matching by default except when part of a built-in literal.
For users introducing new atoms, we recommend wrapping them in dedicated syntax kinds if they
should participate in matching.
For example, in
```lean
syntax "c" ("foo" <|> "bar") ...
```
`foo` and `bar` are indistinguishable during matching, but in
```lean
syntax foo := "foo"
syntax "c" (foo <|> "bar") ...
```
they are not.
-/
@[builtin_term_parser] def «match» 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.nomatch
code: /--
Empty match/ex falso. `nomatch e` is of arbitrary type `α : Sort u` if
Lean can show that an empty set of patterns is exhaustive given `e`'s type,
e.g. because it has no constructors.
-/
@[builtin_term_parser] def «nomatch» 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.nofun
code: @[builtin_term_parser] def «nofun» 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.funImplicitBinder
code: def funImplicitBinder 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.funStrictImplicitBinder
code: def funStrictImplicitBinder 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.funBinder
code: def funBinder : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.basicFun
code: def basicFun : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.fun
code: @[builtin_term_parser] def «fun» 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.optExprPrecedence
code: def optExprPrecedence 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.withAnonymousAntiquot
code: def withAnonymousAntiquot 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.leading_parser
code: @[builtin_term_parser] def «leading_parser»  
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.trailing_parser
code: @[builtin_term_parser] def «trailing_parser» 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.borrowed
code: @[builtin_term_parser] def borrowed   
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.quotedName
code: /-- A literal of type `Name`. -/
@[builtin_term_parser] def quotedName 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.doubleQuotedName
code: /--
A resolved name literal. Evaluates to the full name of the given constant if
existent in the current context, or else fails.
-/
-- use `rawCh` because ``"`" >> ident`` overlaps with `nameLit`, with the latter being preferred by the tokenizer
-- note that we cannot use ```"``"``` as a new token either because it would break `precheckedQuot`
@[builtin_term_parser] def doubleQuotedName 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.letIdBinder
code: def letIdBinder 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.letIdLhs
code: def letIdLhs    : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.letIdDecl
code: def letIdDecl   
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.letPatDecl
code: def letPatDecl  
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.letEqnsDecl
code: def letEqnsDecl 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.letDecl
code: /-- `letDecl` matches the body of a let declaration `let f x1 x2 := e`,
`let pat := e` (where `pat` is an arbitrary term) or `let f | pat1 => e1 | pat2 => e2 ...`
(a pattern matching declaration), except for the `let` keyword itself.
`let rec` declarations are not handled here. -/
def letDecl     
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.let
code: /--
`let` is used to declare a local definition. Example:
```
let x := 1
let y := x + 1
x + y
```
Since functions are first class citizens in Lean, you can use `let` to declare
local functions too.
```
let double := fun x => 2*x
double (double 3)
```
For recursive definitions, you should use `let rec`.
You can also perform pattern matching using `let`. For example,
assume `p` has type `Nat × Nat`, then you can write
```
let (x, y) := p
x + y
```
-/
@[builtin_term_parser] def «let» 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.let_fun
code: /--
`let_fun x := v; b` is syntax sugar for `(fun x => b) v`.
It is very similar to `let x := v; b`, but they are not equivalent.
In `let_fun`, the value `v` has been abstracted away and cannot be accessed in `b`.
-/
@[builtin_term_parser] def «let_fun»     
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.let_delayed
code: /--
`let_delayed x := v; b` is similar to `let x := v; b`, but `b` is elaborated before `v`.
-/
@[builtin_term_parser] def «let_delayed» 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.let_tmp
code: /--
`let`-declaration that is only included in the elaborated term if variable is still there.
It is often used when building macros.
-/
@[builtin_term_parser] def «let_tmp» 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.haveId
code: def haveId 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.haveIdLhs
code: def haveIdLhs    
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.haveIdDecl
code: def haveIdDecl   
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.haveEqnsDecl
code: def haveEqnsDecl 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.haveDecl
code: /-- `haveDecl` matches the body of a have declaration: `have := e`, `have f x1 x2 := e`,
`have pat := e` (where `pat` is an arbitrary term) or `have f | pat1 => e1 | pat2 => e2 ...`
(a pattern matching declaration), except for the `have` keyword itself. -/
def haveDecl     
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.have
code: @[builtin_term_parser] def «have» 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.haveI
code: /-- `haveI` behaves like `have`, but inlines the value instead of producing a `let_fun` term. -/
@[builtin_term_parser] def «haveI» 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.letI
code: /-- `letI` behaves like `let`, but inlines the value instead of producing a `let_fun` term. -/
@[builtin_term_parser] def «letI» 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.scoped
code: def «scoped» 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.local
code: def «local»  
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.attrKind
code: /-- `attrKind` matches `("scoped" <|> "local")?`, used before an attribute like `@[local simp]`. -/
def attrKind 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.attrInstance
code: def attrInstance     
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.attributes
code: def attributes       
goal: Lean.Parser.Parser

full_name: Lean.Parser.Termination.terminationBy
code: /--
Specify a termination argument for well-founded termination:
```
termination_by a - b
```
indicates that termination of the currently defined recursive function follows
because the difference between the the arguments `a` and `b`.

If the fuction takes further argument after the colon, you can name them as follows:
```
def example (a : Nat) : Nat → Nat → Nat :=
termination_by b c => a - b
```

If omitted, a termination argument will be inferred. If written as `termination_by?`,
the inferrred termination argument will be suggested.
-/
def terminationBy 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Termination.terminationBy?
code: @[inherit_doc terminationBy]
def terminationBy? 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Termination.decreasingBy
code: /--
Manually prove that the termination argument (as specified with `termination_by` or inferred)
decreases at each recursive call.

By default, the tactic `decreasing_tactic` is used.
-/
def decreasingBy 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Termination.suffix
code: /--
Termination hints are `termination_by` and `decreasing_by`, in that order.
-/
def suffix 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.letRecDecl
code: /-- `letRecDecl` matches the body of a let-rec declaration: a doc comment, attributes, and then
a let declaration without the `let` keyword, such as `/-- foo -/ @[simp] bar := 1`. -/
def letRecDecl       
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.letRecDecls
code: /-- `letRecDecls` matches `letRecDecl,+`, a comma-separated list of let-rec declarations (see `letRecDecl`). -/
def letRecDecls      
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.letrec
code: @[builtin_term_parser]
def «letrec» 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.whereDecls
code: @[run_builtin_parser_attribute_hooks]
def whereDecls 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.matchAltsWhereDecls
code: @[run_builtin_parser_attribute_hooks]
def matchAltsWhereDecls 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.noindex
code: @[builtin_term_parser] def noindex 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.unsafe
code: /--
`unsafe t : α` is an expression constructor which allows using unsafe declarations inside the
body of `t : α`, by creating an auxiliary definition containing `t` and using `implementedBy` to
wrap it in a safe interface. It is required that `α` is nonempty for this to be sound,
but even beyond that, an `unsafe` block should be carefully inspected for memory safety because
the compiler is unable to guarantee the safety of the operation.

For example, the `evalExpr` function is unsafe, because the compiler cannot guarantee that when
you call ```evalExpr Foo ``Foo e``` that the type `Foo` corresponds to the name `Foo`, but in a
particular use case, we can ensure this, so `unsafe (evalExpr Foo ``Foo e)` is a correct usage.
-/
@[builtin_term_parser] def «unsafe» 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.binrel
code: /-- `binrel% r a b` elaborates `r a b` as a binary relation using the type propogation protocol in `Lean.Elab.Extra`. -/
@[builtin_term_parser] def binrel 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.binrel_no_prop
code: /-- `binrel_no_prop% r a b` is similar to `binrel% r a b`, but it coerces `Prop` arguments into `Bool`. -/
@[builtin_term_parser] def binrel_no_prop 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.binop
code: /-- `binop% f a b` elaborates `f a b` as a binary operation using the type propogation protocol in `Lean.Elab.Extra`. -/
@[builtin_term_parser] def binop 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.binop_lazy
code: /-- `binop_lazy%` is similar to `binop% f a b`, but it wraps `b` as a function from `Unit`. -/
@[builtin_term_parser] def binop_lazy 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.leftact
code: /-- `leftact% f a b` elaborates `f a b` as a left action using the type propogation protocol in `Lean.Elab.Extra`.
In particular, it is like a unary operation with a fixed parameter `a`, where only the right argument `b` participates in the operator coercion elaborator. -/
@[builtin_term_parser] def leftact 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.rightact
code: /-- `rightact% f a b` elaborates `f a b` as a right action using the type propogation protocol in `Lean.Elab.Extra`.
In particular, it is like a unary operation with a fixed parameter `b`, where only the left argument `a` participates in the operator coercion elaborator. -/
@[builtin_term_parser] def rightact 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.unop
code: /-- `unop% f a` elaborates `f a` as a unary operation using the type propogation protocol in `Lean.Elab.Extra`. -/
@[builtin_term_parser] def unop 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.forInMacro
code: @[builtin_term_parser] def forInMacro 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.forInMacro'
code: @[builtin_term_parser] def forInMacro' 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.declName
code: /-- A macro which evaluates to the name of the currently elaborating declaration. -/
@[builtin_term_parser] def declName 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.withDeclName
code: /--
* `with_decl_name% id e` elaborates `e` in a context while changing the effective
  declaration name to `id`.
* `with_decl_name% ?id e` does the same, but resolves `id` as a new definition name
  (appending the current namespaces).
-/
@[builtin_term_parser] def withDeclName 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.typeOf
code: @[builtin_term_parser] def typeOf 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.ensureTypeOf
code: @[builtin_term_parser] def ensureTypeOf 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.ensureExpectedType
code: @[builtin_term_parser] def ensureExpectedType 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.noImplicitLambda
code: @[builtin_term_parser] def noImplicitLambda 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.clear
code: /--
`clear% x; e` elaborates `x` after clearing the free variable `x` from the local context.
If `x` cannot be cleared (due to dependencies), it will keep `x` without failing.
-/
@[builtin_term_parser] def clear 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.letMVar
code: @[builtin_term_parser] def letMVar 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.waitIfTypeMVar
code: @[builtin_term_parser] def waitIfTypeMVar 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.waitIfTypeContainsMVar
code: @[builtin_term_parser] def waitIfTypeContainsMVar 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.waitIfContainsMVar
code: @[builtin_term_parser] def waitIfContainsMVar 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.defaultOrOfNonempty
code: @[builtin_term_parser] def defaultOrOfNonempty 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.noErrorIfUnused
code: /--
Helper parser for marking `match`-alternatives that should not trigger errors if unused.
We use them to implement `macro_rules` and `elab_rules`
-/
@[builtin_term_parser] def noErrorIfUnused 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.namedArgument
code: def namedArgument  
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.ellipsis
code: def ellipsis       
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.argument
code: def argument       
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.app
code: @[builtin_term_parser] def app 
goal: Lean.Parser.TrailingParser

full_name: Lean.Parser.Term.proj
code: /--
The *extended field notation* `e.f` is roughly short for `T.f e` where `T` is the type of `e`.
More precisely,
* if `e` is of a function type, `e.f` is translated to `Function.f (p := e)`
  where `p` is the first explicit parameter of function type
* if `e` is of a named type `T ...` and there is a declaration `T.f` (possibly from `export`),
  `e.f` is translated to `T.f (p := e)` where `p` is the first explicit parameter of type `T ...`
* otherwise, if `e` is of a structure type,
  the above is repeated for every base type of the structure.

The field index notation `e.i`, where `i` is a positive number,
is short for accessing the `i`-th field (1-indexed) of `e` if it is of a structure type. -/
@[builtin_term_parser] def proj     
goal: Lean.Parser.TrailingParser

full_name: Lean.Parser.Term.completion
code: @[builtin_term_parser] def completion 
goal: Lean.Parser.TrailingParser

full_name: Lean.Parser.Term.arrow
code: @[builtin_term_parser] def arrow    
goal: Lean.Parser.TrailingParser

full_name: Lean.Parser.Term.identProjKind
code: /--
Syntax kind for syntax nodes representing the field of a projection in the `InfoTree`.
Specifically, the `InfoTree` node for a projection `s.f` contains a child `InfoTree` node
with syntax ``(Syntax.node .none identProjKind #[`f])``.

This is necessary because projection syntax cannot always be detected purely syntactically
(`s.f` may refer to either the identifier `s.f` or a projection `s.f` depending on
the available context).
-/
def identProjKind 
goal: Lean.Name

full_name: Lean.Parser.Term.isIdent
code: def isIdent (stx : Syntax) : Bool 
goal: Bool

full_name: Lean.Parser.Term.explicitUniv
code: /-- `x.{u, ...}` explicitly specifies the universes `u, ...` of the constant `x`. -/
@[builtin_term_parser] def explicitUniv : TrailingParser 
goal: Lean.Parser.TrailingParser

full_name: Lean.Parser.Term.namedPattern
code: /-- `x@e` or `x@h:e` matches the pattern `e` and binds its value to the identifier `x`.
If present, the identifier `h` is bound to a proof of `x = e`. -/
@[builtin_term_parser] def namedPattern : TrailingParser 
goal: Lean.Parser.TrailingParser

full_name: Lean.Parser.Term.pipeProj
code: /--
`e |>.x` is a shorthand for `(e).x`.
It is especially useful for avoiding parentheses with repeated applications.
-/
@[builtin_term_parser] def pipeProj   
goal: Lean.Parser.TrailingParser

full_name: Lean.Parser.Term.pipeCompletion
code: @[builtin_term_parser] def pipeCompletion 
goal: Lean.Parser.TrailingParser

full_name: Lean.Parser.Term.subst
code: /--
`h ▸ e` is a macro built on top of `Eq.rec` and `Eq.symm` definitions.
Given `h : a = b` and `e : p a`, the term `h ▸ e` has type `p b`.
You can also view `h ▸ e` as a "type casting" operation
where you change the type of `e` by using `h`.

The macro tries both orientations of `h`. If the context provides an
expected type, it rewrites the expeced type, else it rewrites the type of e`.

See the Chapter "Quantifiers and Equality" in the manual
"Theorem Proving in Lean" for additional information.
-/
@[builtin_term_parser] def subst 
goal: Lean.Parser.TrailingParser

full_name: Lean.Parser.Term.bracketedBinderF
code: def bracketedBinderF 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.«instCoeTSyntaxConsSyntaxNodeKindMkStr4Nil_.lake_1»
code: instance : Coe (TSyntax ``bracketedBinderF) (TSyntax ``bracketedBinder) 
goal: Coe (Lean.TSyntax `Lean.Parser.Term.bracketedBinderF) (Lean.TSyntax `Lean.Parser.Term.bracketedBinder)

full_name: Lean.Parser.Term.panic
code: /--
`panic! msg` formally evaluates to `@Inhabited.default α` if the expected type
`α` implements `Inhabited`.
At runtime, `msg` and the file position are printed to stderr unless the C
function `lean_set_panic_messages(false)` has been executed before. If the C
function `lean_set_exit_on_panic(true)` has been executed before, the process is
then aborted.
-/
@[builtin_term_parser] def panic 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.unreachable
code: /-- A shorthand for `panic! "unreachable code has been reached"`. -/
@[builtin_term_parser] def unreachable 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.dbgTrace
code: /--
`dbg_trace e; body` evaluates to `body` and prints `e` (which can be an
interpolated string literal) to stderr. It should only be used for debugging.
-/
@[builtin_term_parser] def dbgTrace 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.assert
code: /-- `assert! cond` panics if `cond` evaluates to `false`. -/
@[builtin_term_parser] def assert 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.macroArg
code: def macroArg       
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.macroDollarArg
code: def macroDollarArg 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.macroLastArg
code: def macroLastArg   
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.stateRefT
code: @[builtin_term_parser] def stateRefT 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.dynamicQuot
code: @[builtin_term_parser] def dynamicQuot 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.dotIdent
code: @[builtin_term_parser] def dotIdent 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.showTermElabImpl
code: /--
Implementation of the `show_term` term elaborator.
-/
@[builtin_term_parser] def showTermElabImpl 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.matchExprPat
code: def matchExprPat 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.matchExprAlt
code: def matchExprAlt (rhsParser : Parser) 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.matchExprElseAlt
code: def matchExprElseAlt (rhsParser : Parser) 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.matchExprAlts
code: def matchExprAlts (rhsParser : Parser) 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.matchExpr
code: @[builtin_term_parser] def matchExpr 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Term.letExpr
code: @[builtin_term_parser] def letExpr 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Tactic.quot
code: @[builtin_term_parser default+1] def Tactic.quot : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.Tactic.quotSeq
code: @[builtin_term_parser] def Tactic.quotSeq : Parser 
goal: Lean.Parser.Parser

full_name: Lean.Parser.initFn._@..lake.packages.lean4.src.lean.Lean.Parser.Term._hyg.5380
code: builtin_initialize
  register_parser_alias letDecl
  register_parser_alias haveDecl
  register_parser_alias sufficesDecl
  register_parser_alias letRecDecls
  register_parser_alias hole
  register_parser_alias syntheticHole
  register_parser_alias matchDiscr
  register_parser_alias bracketedBinder
  register_parser_alias attrKind
  register_parser_alias optSemicolon
goal: IO Unit