Zulip Chat Archive
Stream: general
Topic: Question about producing named instances
cognivore (Jun 09 2022 at 20:11):
Hi, sorry for a rather silly beginner question.
Consider the following type and class:
inductive K (T: Type) where
| k (t: List T)
| l (t: List Char)
| m
class C (A: Type) where
Assoc: Type
ordAssoc: Ord Assoc
beqK: BEq (K Assoc)
It's trivial to produce ordAssoc
by selecting a type, which is Ord
.
It's trivial to demonstrate that given Ord T
, we can produce BEq (K T)
.
What I don't understand is how to take the second demonstration (I write it as instance [Ord T]: BEq (K T) where ...
) and shove it into beqK
.
Jannis Limperg (Jun 10 2022 at 06:57):
inferInstance
and inferInstanceAs
are probably what you're looking for.
Maybe this is just a minimisation artifact, but your C
looks fishy: the type A
is never used.
cognivore (Jun 10 2022 at 09:41):
It is a minmisation artefact indeed, I'll look at inferInstance
(I actually found it, but couldn't understand). In the meantime, @Arthur Paulino has shown me that one can simply name an instance
, which makes me feel that even without automatic or semi-automatic resolution, a user should be able to present beqK
.
Jannis Limperg (Jun 10 2022 at 10:06):
Yes, you can name the instance and then the user can give it directly. instance
is syntactic sugar for a structure
with the @[instance]
attribute, so a named instance is roughly the same as @[instance] def myInst [Ord T] : BEq (K T) := ...
. (In fact, all instances are named; if you don't give a name, Lean will invent one.)
inferInstance
gives direct access to typeclass inference. If an instance C A
is registered, inferInstanceAs (C A)
has type C A
(and you don't have to write the instance's name). inferInstance
allows you to omit the C A
if Lean can figure out from context which class and type you mean.
Last updated: Dec 20 2023 at 11:08 UTC