Splitting topology.v
#1167
Labels
renaming/refactoring 🔧
This is about a renaming or refactoring in the library
Milestone
topology.v
#1167
We've discussed at a handful of meetings that
topology.v
is too big at 8000 lines long. It causes at least 3 problems.topology.v
because my IDE has to recheck 1000s of lines of boring stuff before I get to what I'm working on.I propose an organization structure here that'll involve splitting into 4 files. Note that most of the complexity in splitting up the files lives in the middle. The function space topology stuff is easy to split off the end of the file. And the filter stuff should be easy to split off the beginning of the file. But the middle of the file is in "development order" not "theory order". For example, why is the subspace stuff at the end, but product stuff at the beginning? So I propose this as the final layout, and then we do 4, then 1, then the last split.
filters.v
Basically just take all the filter stuff, and cut/paste it. It's mostly in the right order/organization now. But some later stuff should get moved in, such as ultra-filters.
topological_constructions.v
I want to separate all these "basic" topological constructions to clean up the circular dependencies. None of the construction depend on anything more than continuity and filter stuff. This way I don't need to keep moving around results. For example, having to move "continuous_compact" at the end of the file because that's where subspace is defined.
The first thing to define is continuity, and it's most basic properties. We don't want anything else in this file.
Second, building topologies from other structures, and their relationship to continuity/convergence/open/closed.
Third, building new topologies from old ones, and their relationships
function_spaces.v
This is already drafted in #1166. It holds
prod_topology
,compact-open
,uniform family
.topology.v
For what remains, I'd like to reorganize it a bit to consolidate related lemmas some more. I'm also tempted to split out the separation axioms into their own file, so we can build their HB mixins in an nice isolated place. But I think we can declare success without that. If this file ends up being ~3000 lines it's still a big improvement from ~8000
The text was updated successfully, but these errors were encountered: