Equations between morphisms in notebook types#1060
Conversation
252404e to
df2a925
Compare
57ae14a to
c2ef971
Compare
|
I found it was necessary to remove TSIFY annotations from some old types to make the versioning work here. This didn't cause problems on the v0 -> v1 upgrade because the redefined types were structurally identical, but we actually had duplicated type definitions in the WASM output. |
bfadeb0 to
0f76c07
Compare
0f76c07 to
342933e
Compare
There was a problem hiding this comment.
Knowing when to bump the notebook types version can be confusing. The main principle is this: we only bump the version and write a migration for changes that would break existing user data. Changes or additions to the notebook types for which existing data would remain valid do not trigger a version bump.
The most common example of such a safe change is adding new variants to an enum. And fortunately that's exactly what we have here.
So this PR can be much simplified by just adding the Equation variant to the existing v1 type ModelJudgment. We did the same thing when adding instantiations:
cffcd0d to
20606f3
Compare
Ahead of notebook elaboration of equations, this PR introduces equations into the
notebook_typesmodulesmodel, model_judgment, diagram_judgment, thus necessitating an upgrade of notebook types tov2. Other than the modules already listed, the main change of interest is indocument, which includes code for migratingv1tov2documents. The only actual modification this migration requires is changing the version number, but there's some slightly wordy unpacking and repacking seemingly necessary since we have to reconstructModelJudgmentandDiagramJudgmenttypes for the new version.It's probably possible to argue for not bothering with upgrading
DiagramJudgmentat this time, since we have no type theoretic treatment of diagrams yet, but I figured it's a minor enough change which we may want before long and versioningnotebook_typesis a bit fiddly. Some more specific comments are attached in the diff.