Commit 2021-04-30 10:14 4a94b28f
View on Github →feat(category_theory/sites): Sheaves of structures (#5927) Define sheaves on a site taking values in an arbitrary category. Joint with @kbuzzard. cc: @jcommelin, this is a step towards condensed abelian groups. I don't love the names here, design advice (particularly from those who'll use this) more than appreciated. The main points are:
- An 
A-valued presheafP : C^op => Ais defined to be a sheaf (for the topology J) iff for everyX : A, the type-valued presheaves of sets given by sendingU : C^optoHom_{A}(X, P U)are all sheaves of sets. - When 
A = Type, this recovers the basic definition of sheaves of sets. - An alternate definition when 
Cis small, has pullbacks andAhas products is given by an equalizer conditionis_sheaf'. - This is equivalent to the earlier definition.
 - When 
A = Type, this is definitionally equal to the equalizer condition for presieves in sheaf_of_types.lean - When 
Ahas limits and there is a functors : A => Typewhich is faithful, reflects isomorphisms and preserves limits, thenP : C^op => Ais a sheaf iff the underlying presheaf of typesP >>> s : C^op => Typeis a sheaf. (cf https://stacks.math.columbia.edu/tag/0073, which is a weaker version of this statement (it's only over spaces, not sites) and https://stacks.math.columbia.edu/tag/00YR (a), which additionally assumes filtered colimits). A couple of questions for reviewers: - We've now got a ton of equivalent ways of showing something's a sheaf, and it's not the easiest to navigate between them. Is there a nice way around this? I think it's still valuable to have all the ways, since each can be helpful in different contexts but it makes the API a bit opaque. There's also a bit of inconsistency - there's a definition 
yoneda_sheaf_conditionwhich is the same asis_sheaf_forbut the equalizer conditions at the bottom of sheaf_of_types aren't named, they're just somenonempty (is_limit (fork.of_ι _ (w P R)))even though they're also equivalent. - The name 
presieve.is_sheafis stupid, I think I was just lazy with namespaces. I thinkpresieve.family_of_elementsandpresieve.is_sheaf_forare still sensible, since they are relative to a presieve, butis_sheafdoesn't have any reference to presieves in its type. - The equalizer condition of sheaves of types is definitionally the same as the equalizer condition for sheaves of structures, so is there any point in having the former version in the library - the latter is just more general (the same doesn't apply to the actual def of sheaves of structures since that's defined in terms of sheaves of types). The main downside I can see is that it might make the proofs of 
equalizer_sheaf_conditiona bit trickier, but that's about it