Zulip Chat Archive
Stream: lean4
Topic: Delaborator weird behavior
jthulhu (Aug 01 2024 at 14:51):
I've tried to convert existing unexpanders in my code to conditional unexpanders, ie. unexpanders that can be turned on/off with an option.
I have the following code
def lift (α : liftedU) : Type _ := ...
register_option pp.lift : Bool := {
defValue := false
group := "pp"
descr := "(pretty printing) display lift from object-level types to Lean types"
}
@[delab app.lift]
def delab_lift : Delab := do
whenNotPPOption (·.get pp.lift.name pp.lift.defValue) do
let e ← getExpr
guard <| e.isAppOfArity' ``lift 1
let arg ← withAppArg delab
`($arg)
This doesn't work though, in the sense that, even if pp.lift
is false, the delaboration never happens. If, instead, I fully specify the name of lift
, as such @[delab app.Tltt.Hott.lift]
, it works. This looks like a bug, but I'm not sure.
@Kyle Miller
Kyle Miller (Aug 01 2024 at 16:21):
The delab
attribute expects what comes after app
to be the fully qualified name for the constant
Kyle Miller (Aug 01 2024 at 16:23):
One way you can tell whether it's correct is to hover your mouse over the app....
, since for convenience if the constant exists then the delab
attribute makes it hoverable.
Kyle Miller (Aug 01 2024 at 16:24):
Feel free to create a Lean issue with a feature request that @[delab app.lift]
should resolve the name lift
to Tltt.Hott.lift
and then instead add a delaborator with the key app.Tltt.Hott.lift
.
Kyle Miller (Aug 01 2024 at 16:25):
(You can take a look at docs#Lean.PrettyPrinter.Delaborator.getExprKind to see why it works the way it does.)
jthulhu (Aug 02 2024 at 08:43):
Here is the corresponding RFC: #4899.
Kim Morrison (Aug 12 2024 at 00:12):
(Completed in lean#4976.)
Last updated: May 02 2025 at 03:31 UTC