Open cdgls opened 8 years ago
It occurs to me that if you use the current theorem function to create your definitions, then globular knows the desired link between them. [Is this how you are already making your definitions?] So possibly a single core change regarding the signature really does take care of both the definition and theorem issues. (But I maintain having them typed separately is useful for various reasons discussed (esp to allow the functionality of theorems without proofs) --- cf also you need the type distinction to ease the work of the auto paper generator.)
I totally agree with this. I think semantically, there are only 2 different kinds of objects in globular: "cells" and "cell-definitions" (which are currently not distinguished, except in how they are created). Like in other proof assistants, we could allow the user to name cells in different ways, to give some "meta" information about how they are being used. A cell without a definition is an axiom, generator, or conjecture. A cell with a definition is a proposition, lemma, theorem, corollary, etc. or a defined cell. Then the associated "cell-definition" (if there is one) would receive the appropriate name ("proof" or "definition"). This idea of treating proofs and definitions as the same thing internally while allowing meaningful names to the user has lots of precent, e.g. in curry/howard provers like Coq.
Something that would make the status of a cell more clear is if its definition (aka proof) appeared directly under the cell, or could be made to appear e.g. by clicking a "+" underneath.
Hi Chris,
Thanks for these really interesting ideas. There's definitely massive scope for making large Globular workspaces easier to understand. Let's discuss and decide what we think the best approach might be.
The biggest potential danger is that the interface is made more complicated. The simplicity of the current interface is something that people really seem to appreciate (I had some comments about this at a workshop only last week.) Once people understand the slogan 'equality via rewriting', there is nothing standing in their way to constructing complex proofs and workspaces, and I don't want to make it harder. That is not to say I do not understand where you are coming from; I have also experienced frustrating working with big workspaces.
The most fundamental issue here seems to be one of proof and certification. I propose the following scheme. Generators have a check box called 'Axiom', set by the user, and a check box called 'Proved', set by the system. The 'Proved' attribute is set for a generator under the following conditions: when it is an axiom, or when it can be rewritten in one step by any generator into a composite of proved generators (a 'proved diagram'). The interpretation (unless I have miscalculated) is that a generator is 'Proved' when follows from the generators. In particular, if you build a proved diagram and click 'Theorem', the resulting theorem (and proof) will be 'Proved'. In the case that only the theorem and not the proof is constructed initially, the 'Proved' certification will be automatically assigned later when the proof is appropriately constructed. (This isn't very far from your suggestion about using the dependency tree.)
Note Globular is actually doing something here - it isn't just extra UI bells and whistles for no functional gain. I think it would resolve the main issue you raise, in a way that can be completely ignored by new users if desired. Other issues you outline (eg quickly finding the 'proof' generators of 'theorem' generators in a big signature) could be solved by small UI tweaks (like a little link underneath a theorem to jump you to the proof lower down in the signature.)
By the way, there is indeed no link stored between theorem and proof generators. But they can be identified by by their properties: the proof has a source diagram of length 1, and a target diagram not involving the unique generator in the source.
Hard-coding concepts like theorems, proofs, definitions, etc, seems the wrong direction, in my view. Some reasons: it's extra formal structure which users might wrongly believe is actually doing something essential; definitions/proofs are functionally identical, and giving apparently-separate mechanisms for them risks cluttering the UI and confusing users who can't see the distinction; having special 'links' between generators requires extra data to keep track of, which the user presumably needs to be able to modify by some mechanism (eg how do you modify the proof of an established theorem without deleting the theorem statement? Note there is no problem with this under the current scheme) which would also have to be coded; what if you want to change perspective and recast a theorem as a definition or vice versa (yet another UI needed); ...
Cheers Jamie
On 1 May 2016 1:02 a.m., "cdgls" notifications@github.com wrote:
I know we've discussed this before, but yesterday Andre and I were attempting to make some headway on one of our globular projects, and it prompts us to raise it again ...
-- We think globular should have the functionality of Definitions and Theorems, not merely treat everything as just another cell of the appropriate dimension.
Let me first try to explain why this is so important, and then detail what it should be like (though exactly what might bear further discussion/revision). This is a substantial enough change to globular, that it would be worth discussing with other users whether they agree this would be worthwhile.
-- Why. One of the core purposes of globular, one might say the core purpose of globular, is to enable the machine certification of certain statements. We argue that it does not at present achieve this purpose, though it appears to for the simple kinds of examples that we all have so far used it for. The view that it does provide certification comes from looking at a globular worksheet, and seeing a statement cell and finding a cell of 1 higher dimension that "proves" the statement cell. But this involves a human belief or check that the "proof" cell actually does prove the statement cell, in terms of other cells which are "known" to be true. There is nothing in globular at present that checks this or confirms it. Indeed, you can just create a cell of the appropriate dimension that has the statement cell as source and any target you like, and it looks like a cell proving that statement. (Remark: it is possible that behind the scenes, globular keeps track of the connection b etween statements and proofs when they are created with the 'theorem' command, but if so, that isn't a connection that is visible to or usable by the end user at present.)
You might say, 'well, don't create random cells that looks like proofs but aren't! that's like writing "Proof. Ha ha, gotcha. QED" in a paper.' But aren't we not supposed to have to trust the author of a globular file? Isn't globular supposed to assure us that what was claimed was actually done? Of course in simple examples, you can kindof follow the globular signature and see that indeed everything has been done. But in larger or more complicated signatures, this can become difficult or impossible. It could even happen that the author genuinely thinks she has proven the statement, but actually somewhere in the middle used a cell that was not reducable to known cells. Globular could certify this has not happened, but at present it does not.
Here's another, closely related reason. When developing a globular proof, you sometimes know certain things are true, but haven't yet written down proofs of them. So you can't use the theorem function, you have to create the statements of the theorems by hand. But then you can't later use the theorem function to prove them, in fact you are stuck. And moreover, with a complicated signature, it can be unclear whether or not those 'theorem's even have proofs in the signature! (Recall there is no user visible difference between a cell that states a theorem but has no proof, and a cell that states a theorem but has a proof buried 20 scroll-pages of cells later in the signature. (Or even a cell that states a theorem but has a cell later that looks like a proof but isn't actually a proof, as mentioned earlier.)) You could say, 'well, don't do that, only use things you've actually proven!' In which case I ask you, 'have you ever written a research paper like that, linearly from st art to finish? you often need to write a bunch of statements to figure out how they best fit together (or indeed which ones you will need in the end, or indeed which ones are true) before it makes sense to go back and write in the proofs.' In any case, this is the actual situation we are in, that we need to write a bunch of lemmas, and only once we've figured out that the lemmas fit together to prove the theorems, does it make any sense to go back and push through the proofs of the lemmas.
-- What. At present there is only a single type of thing that exists in the signature. We believe there should be at least five types of things: Postulates/Axioms, DefinedCells, Definitions, Theorems, Proofs. (Of course, one can alias to allow Theorems to be called also Lemmas or Propositions or Corollaries (with no functional change).) There are reasons we write papers with these headers that distinguish information types, and we think globular will benefit from them.
Postulates/Axioms. These are cells that are assumed to exist. "Assume there is a 0-cell Blue. Assume there is a 0-cell Red. Assume there is a 1-cell from Blue to Red." (I'll use http://globular.science/1512.007 as a reference point.) At present, every cell is treated as a postulate (from a user's viewpoint---we don't know if internally globular already makes some distinctions).
Definitions. There should be definition types. So for instance, in our reference worksheet, "New Cup" is a 2-cell, and then there is an invertible 3-cell "New Cup Definition". (Woe be you if you forgot to name this cell properly, or if the name is too long that you can't see the "Definition" part at the end.) But in reality, we don't ever want to think about or use that 3-cell except as a substitution mechanism, much less use any of the higher invertible structure. Instead of two things in the signature (one 2-cell and one 3-cell), there should be just a single item in the signature, listed at the level of 2-cells [But this item can have two parts, the thing being defined, and the definition]:
"DefinedItem: CupBeingDefined ____Definition: [CupBeingDefined] := [OldCup with bump]"
Note: for this item (Definitions), it may be that the internal structure of globular doesn't have to change at all --- maybe this is 'just a UI issue', in the sense that perhaps you still want to be able to click on the [CupBeingDefined] 2-cell and have it in its compressed form, and then click on the 'definition' to expand the compressed picture into the uncompressed picture, much as it does at present. So perhaps all the request amounts to is that there be a definite link between a cell that is being defined and the cell that is the definition. And the suggestion is that the link should be that they are either part of the same item of the signature, or adjacent in the signature (perhaps with the definition indented subordinately to the thing being defined, as displayed above).
Remark: To aim for minimal changes to the UI (since I can only imagine what a nightmare UI issues are to implement), perhaps the different cell types can be distinguished simply by adding a little "A" [Axiom], "C" [cell being defined], "D" [definition of a cell], "T" [theorem], "Pf" [proof] in the lower right corner of the cell box, or something.
Theorems & Proofs. There should be cells with type 'Theorem', and there are two subtypes 'Proven', 'Unproven'. So you can create a 3-cell of type Theorem, and by default it is unproven (perhaps there is a "Tu" in the corner, or if you prefer you can gloss unproven theorems as 'conjectures'). So in our example, you create a cell (type Theorem-unproven) from the snake to the identity and call it "Theorem 1". This is aspirational, and there are no 4-cells yet.
Then you can prove the theorem by creating a 3-cell with the features: 1. has source the source of the theorem, 2. has target the target of the theorem, 3. is built from other preexisting 3-cells in the signature (whatever the type of those cells). Once this 'Proof' 3-cell exists, the type of the theorem cell changes from 'Theorem-unproven' to 'Theorem-proven' "Tp". Of course, it is proven modulo earlier cells, which may themselves be unproven.
But crucially, globular should maintain a graph of the dependencies of the theorem cells, and then it's easy to ask globular whether the graph of dependencies of every theorem cell bottoms out into axiom cells, or if there are some leaves that have type 'Theorem-unproven'. This is the core verification that is missing in the situation discussed in the "Why" section above.
As with the 'Cell defined' and 'Definition' being linked and displayed adjacently, the Theorem and its Proof should be linked and displayed adjacently. Again, this could be done as
"Theorem 1 ____Proof 1"
ie the Proof is subordinately indented to the theorem [and it's easy to see if there is no proof there] [and they are part of the same item of the signature].
Again, you might say it is useful to have the proof still exist as an n+1
- cell (as it does now), and I can see that, and see that it would require less internal change to the structure of globular to have it be so. So maybe the [Theorem+Proof] item in the signature is a pair of an [n-cell + (n+1)-cell], just like the [Cell defined + Definition] pair. If so, maybe the globular core encoding doesn't have to change, other than having a way to keep track of the linkages between [Cell defined] and [Definition] and between [Theorem] and [Proof], and to change the UI to reflect these linkages, and to allow [Theorems] that don't yet have [Proofs], [and to give every cell one of the five types], [and to have a way to see or at least query the dependency tree among the theorems].
I can imagine objections to this proposal, but anyway, that's the thought to consider/discuss.
In conclusion: globular is super cool.
— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub
Correction:
The interpretation (unless I have miscalculated) is that a generator is 'Proved' when follows from the generators.
I meant to write "when it follows from the axioms".
Hi, some more comments.
you sometimes know certain things are true, but haven't yet written down proofs of them. ... [so] you have to create the statements of the theorems by hand. But then you can't later use the theorem function to prove them, in fact you are stuck.
You're not stuck: you just make a new generator whose source is your 'theorem', and whose target is the 'proof' you have built. (Note there is no problem choosing the 'target' before the 'source' when constructing a new generator.
There should be definition types. ... in reality, we don't ever want to think about or use that 3-cell except as a substitution mechanism, much less use any of the higher invertible structure.
I strongly disagree. For example, maybe you're building a big proof, and at some point you need to insert an X, X^{-1} pair, where X is some important generator, which happens to be defined in terms of other stuff. In fact, I think I have done this myself several times in proofs.
This idea of treating proofs and definitions as the same thing internally while allowing meaningful names to the user has lots of precent, e.g. in curry/howard provers like Coq.
That's interesting. In essence, as I said above, I worry about the encumbrance of the additional UI required to create, display and edit this information; the additional effort required by new users to understand the prover environment; the extra distance from the underlying mathematics; the fact that (aside from absolutely genuine practical issues of getting 'lost in the signature') these extra UI concepts are strictly unnecessary (is this really also the case for Coq, as you imply?); and so on. (Not to mention programmer effort!)
Cheers, Jamie
I agree that it isn't obvious what the best approach is to all this, but to push the discussion, some further questions/thoughts ...
I have a few more comments, will add shortly.
Also, to continue a bit the analogy with Coq (which also represents definitions and proofs as the same kind of thing, via curry-howard), the reason proofs and definitions are kept separate roughly breaks down as follows:
Proof: "I don't care how this thing is defined, as long as it has the right type" Definition: "This accomplishes a particular task (e.g. a function that reverses lists), so I do care how this is defined."
This has a few practical consequences in the implementation (proof terms are sometimes thrown away to save space/time), but it is 90% about letting humans keep these two concepts separate. An example in Globular:
Definition: the "sock"-shaped cup Proof: proof that the "sock" satisfies a yanking equation with the cap.
I agree that it isn't obvious what the best approach is to all this, but to push the discussion, some further questions/thoughts ...
1.
If you don't type proofs and definitions separately, then how is the automatic paper generator going to know how to treat them separately (which is certainly necessary for approximating the desired output)? We want globular to turn "Cell X [definition] Cell Y [definition of cell X]" into "\begin{definition} X := target(Y) \end{definition}" while turning "Cell X [theorem] Cell Y [proof]: into "\begin{theorem} X \end{theorem} \begin{proof} target(Y) \end{proof}" Those are substantively different, both from the perspective of a human author and a human reader. 2.
You argue partly based on 'the additional effort required by new users' and 'the extra distance from the underlying mathematics'. I strongly believe that typing definitions and proofs separately will make it easier for almost all users to use globuar (both new and experienced users alike), and that this brings globular closer to, not farther from, the underlying mathematics. Regarding the first claim, I think most new users experience a hiccup in working with globular, because it departs from the standard mental convention of having definitions and proofs be very different sorts of constructions. Moreover, in my experience this hiccup does not dissipate, but is actually exacerbated as the use of globular becomes more complicated and intense --- I think the reason is that whether globular likes it or not, we do actually mentally think of definitions as different from proofs and we use them differently in making arguments, and any additional cognitive dissonance is am plified in a complex situation. Regarding the second claim, I'd say that the 'underlying mathematics' is what is in our head, more than what is stored inside the guts of globular, and that's the standard we should look to for comparison.
I have a few more comments, will add shortly.
— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/jamievicary/globular/issues/39#issuecomment-216243802
Okay, so I think the main items under consideration are:
Did I miss any?
I'm sympathetic to wanting to keep the UI simple and streamlined, and I think that is possible.
More in a separate comment.
Comment 1: I actually just now had the experience of looking at a workspace with someone (who created that workspace at some earlier time), and it was a challenge to figure out what was happening (primarily because it wasn't clear which cells were assumed to exist as part of the setup and which were going to be defined later on in the signature --- note that this isn't an issue resolved by putting "Th" and "Pf" and "Def" in the names of your cells, because there are five, not four, types that need distinguishing --- we don't have a standard name for the fifth type (CellWithADefinition) because we don't usually do mathematics insisting that definitions are invertible cells of one higher dimension).
Comment 2: One objection to typing that I am sympathetic too, which Jamie mentioned earlier, is imagining the situation where you have something that you thought of as a theorem and proof, and then you decide you want to think of it as a cellwithadefinition and definition, and continue on working with that as such. In theory, that could happen, but in practice, it has not happened to me (whereas the issues with lack of typing have), and I think it will be a pretty rare occurrence --- usually we have a priori a category level we care about (eg 3) and we will think about everything before the top level as a construction where we care about the details, and everything at the top level as a proof where, as Alex described, we don't care about the exact path because we don't expect to reuse it at any higher level. So I think the other issues outweigh this objection.
Correct me if I'm wrong, but reading the above comments, it seems like we are already roughly in agreement that all of 1,2,3,4 are worth doing.
I suggest "Named" and "Definition" for the analogues of "Theorem" and "Proof".
I think we have a sketch of an approach we can all agree on here.
Just to be clear, regarding 4, what I suggested in my earlier email is I believe more flexible, as it would only require users to use "Axiom" cells, and not the other new structure. After all: suppose X is a named generator, defined (using the new UI structure we've been discussing) in terms of some unproved stuff. Then imagine that, separately, Y is an axiom generator whose source is X, and whose target is a composite of axioms. Then surely X ought to be labeled as proved. On 2 May 2016 5:06 p.m., "cdgls" notifications@github.com wrote:
Okay, so I think the main items under consideration are:
1.
Some UI indication of type (Axiom, CellWithADefinition, Definition, Theorem, Proof). (What the heck should that second type be called?) 2.
Some UI link between each CellWithADefinition and its Definition, and between each Theorem and its Proof (if the proof exists). 3.
Some UI way to create a CellWithADefinition on its own, and then create its Definition, and similarly (by the identical mechanism) to create a Theorem on its own (with no proof), and then at a separate time to create its Proof. 4.
Some way to ask globular or see whether a theorem has a complete proof (ie a proof whose dependency tree bottoms out in Axioms, never in a theorem without a proof).
Did I miss any?
I'm sympathetic to wanting to keep the UI simple and streamlined, and I think that is possible.
More in a separate comment.
Comment 1: I actually just now had the experience of looking at a workspace with someone (who created that workspace at some earlier time), and it was a challenge to figure out what was happening (primarily because it wasn't clear which cells were assumed to exist as part of the setup and which were going to be defined later on in the signature --- note that this isn't an issue resolved by putting "Th" and "Pf" and "Def" in the names of your cells, because there are five, not four, types that need distinguishing --- we don't have a standard name for the fifth type (CellWithADefinition) because we don't usually do mathematics insisting that definitions are invertible cells of one higher dimension).
Comment 2: One objection to typing that I am sympathetic too, which Jamie mentioned earlier, is imagining the situation where you have something that you thought of as a theorem and proof, and then you decide you want to think of it as a cellwithadefinition and definition, and continue on working with that as such. In theory, that could happen, but in practice, it has not happened to me (whereas the issues with lack of typing have), and I think it will be a pretty rare occurrence --- usually we have a priori a category level we care about (eg 3) and we will think about everything before the top level as a construction where we care about the details, and everything at the top level as a proof where, as Alex described, we don't care about the exact path because we don't expect to reuse it at any higher level. So I think the other issues outweigh this objection.
— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/jamievicary/globular/issues/39#issuecomment-216278260
I have in mind that we should carefully consider this 'provable' condition for generators, so that it matches something elegant in homotopy theory.
Imagine everything in the signature is invertible, so you're really building some CW complex. You mark every generator as an "Axiom". Then, you add some more stuff, giving a CW complex with more generators. Then one can reasonably ask: is it trivial to see, with this data, that the CW complex I've defined is homotopic to the one I started with (ie the "Axiom" subset)? And in particular, for every generating cell, you can ask: is this homotopic to a composite of axioms.
It would be cool if there was some simple algorithm for this, which also worked nicely in the noninvertible case to correctly decide the truth status of generators. On 2 May 2016 5:43 p.m., "Jamie Vicary" jamievicary@gmail.com wrote:
I suggest "Named" and "Definition" for the analogues of "Theorem" and "Proof".
I think we have a sketch of an approach we can all agree on here.
Just to be clear, regarding 4, what I suggested in my earlier email is I believe more flexible, as it would only require users to use "Axiom" cells, and not the other new structure. After all: suppose X is a named generator, defined (using the new UI structure we've been discussing) in terms of some unproved stuff. Then imagine that, separately, Y is an axiom generator whose source is X, and whose target is a composite of axioms. Then surely X ought to be labeled as proved. On 2 May 2016 5:06 p.m., "cdgls" notifications@github.com wrote:
Okay, so I think the main items under consideration are:
1.
Some UI indication of type (Axiom, CellWithADefinition, Definition, Theorem, Proof). (What the heck should that second type be called?) 2.
Some UI link between each CellWithADefinition and its Definition, and between each Theorem and its Proof (if the proof exists). 3.
Some UI way to create a CellWithADefinition on its own, and then create its Definition, and similarly (by the identical mechanism) to create a Theorem on its own (with no proof), and then at a separate time to create its Proof. 4.
Some way to ask globular or see whether a theorem has a complete proof (ie a proof whose dependency tree bottoms out in Axioms, never in a theorem without a proof).
Did I miss any?
I'm sympathetic to wanting to keep the UI simple and streamlined, and I think that is possible.
More in a separate comment.
Comment 1: I actually just now had the experience of looking at a workspace with someone (who created that workspace at some earlier time), and it was a challenge to figure out what was happening (primarily because it wasn't clear which cells were assumed to exist as part of the setup and which were going to be defined later on in the signature --- note that this isn't an issue resolved by putting "Th" and "Pf" and "Def" in the names of your cells, because there are five, not four, types that need distinguishing --- we don't have a standard name for the fifth type (CellWithADefinition) because we don't usually do mathematics insisting that definitions are invertible cells of one higher dimension).
Comment 2: One objection to typing that I am sympathetic too, which Jamie mentioned earlier, is imagining the situation where you have something that you thought of as a theorem and proof, and then you decide you want to think of it as a cellwithadefinition and definition, and continue on working with that as such. In theory, that could happen, but in practice, it has not happened to me (whereas the issues with lack of typing have), and I think it will be a pretty rare occurrence --- usually we have a priori a category level we care about (eg 3) and we will think about everything before the top level as a construction where we care about the details, and everything at the top level as a proof where, as Alex described, we don't care about the exact path because we don't expect to reuse it at any higher level. So I think the other issues outweigh this objection.
— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/jamievicary/globular/issues/39#issuecomment-216278260
Following a discussion with Jamie, the proposal is the following.
(1) In the lower right corner of each cell box, there will be a small box
[ ]
This will be empty by default. But you can click on it and specify the type of the cell. The options will be
Axiom [A] Named [N](This is a cell that is being defined as something else --- if you have a better idea than 'Named' for what to call this, say so) Definition [D] Theorem [T] Proof [P]
(2) A cell of type N resp. D will be linked to at most one (in particular possibly zero) cells of type D resp. N. Similarly a cell of type T resp. P will be linked to at most one cells of type P resp T.
If one of these cells is so linked, there will be a second small box, appearing to left of the first small box, containing an arrow
[V] [T]
(that V is meant to look like an arrow), and clicking on the arrow will scroll the signature down or up to the corresponding definition/proof/etc.
When selecting the type of a cell by hand, if the selected type is NDTP, there will be an option to specify the cell it is linked to.
(3) If the user uses the type mechanism at all, then there will be some procedure whereby globular uses the type information to determine which of the cells are "proven". For a cell that is not proven, a "C" (for conjecture) will appear under the X in the upper right of the cell box.
Exactly what the procedure here is remains unclear to me.
I would furthermore add another gray function box on the right called "Definition", such that "Definition" and "Theorem" do exactly the same thing except that "Definition" labels the two cells created with type N and D, while Theorem labels them T and P.
However, I think Jamie feels this redundancy of UI is not desirable. (And I can see that perspective too.)
Regarding the determination of which cells are 'proven'. Jamie had an idea for how to do this only using the information of which cells are typed "Axiom" and which are not. Namely, a cell is proved if it can be rewritten in a single step using an invertible generator into a composite of cells that are already proved.
My concern with that is, how do the cells which we think of as "proofs" and "definitions" get their status as proved? They typically cannot be rewritten as anything, so they fail the condition, and yet they certainly aren't typed as axioms.
If every cell is typed (by one of ANDTP), then one can just do this: Axioms are proven; Definitions and Proofs are proven if their target is a composite of proven cells; Named and Theorems are proven exactly when they have a linked proven Definition or proven Proof.
(Note that a proof can certainly be unproven here, for instance when its target is a composite of Lemmas that don't yet have proofs.)
Hi, I agree with this new definition of the 'Proven' predicate. As we discussed in person, there is the possibility of getting into a cycle when determining if something is proven; this will have to be detected, and result in the proven attribute not being assigned.
As we also discussed, a nice feature is that this is close to the notion of simple homotopy equivalence of topological spaces.
A minor suggestion --- let's not describe this as "typing" a cell; one might hope for future extensions to Globular allowing some amount of dependent typing in the usual sense, and it would be a shame if the word were already taken.
I like Jamie's language describing these as "predicates".
I know we've discussed this before, but yesterday Andre and I were attempting to make some headway on one of our globular projects, and it prompts us to raise it again ...
-- We think globular should have the functionality of Definitions and Theorems, not merely treat everything as just another cell of the appropriate dimension.
Let me first try to explain why this is so important, and then detail what it should be like (though exactly what might bear further discussion/revision). This is a substantial enough change to globular, that it would be worth discussing with other users whether they agree this would be worthwhile.
-- Why. One of the core purposes of globular, one might say the core purpose of globular, is to enable the machine certification of certain statements. We argue that it does not at present achieve this purpose, though it appears to for the simple kinds of examples that we all have so far used it for. The view that it does provide certification comes from looking at a globular worksheet, and seeing a statement cell and finding a cell of 1 higher dimension that "proves" the statement cell. But this involves a human belief or check that the "proof" cell actually does prove the statement cell, in terms of other cells which are "known" to be true. There is nothing in globular at present that checks this or confirms it. Indeed, you can just create a cell of the appropriate dimension that has the statement cell as source and any target you like, and it looks like a cell proving that statement. (Remark: it is possible that behind the scenes, globular keeps track of the connection between statements and proofs when they are created with the 'theorem' command, but if so, that isn't a connection that is visible to or usable by the end user at present.)
You might say, 'well, don't create random cells that looks like proofs but aren't! that's like writing "Proof. Ha ha, gotcha. QED" in a paper.' But aren't we not supposed to have to trust the author of a globular file? Isn't globular supposed to assure us that what was claimed was actually done? Of course in simple examples, you can kindof follow the globular signature and see that indeed everything has been done. But in larger or more complicated signatures, this can become difficult or impossible. It could even happen that the author genuinely thinks she has proven the statement, but actually somewhere in the middle used a cell that was not reducable to known cells. Globular could certify this has not happened, but at present it does not.
Here's another, closely related reason. When developing a globular proof, you sometimes know certain things are true, but haven't yet written down proofs of them. So you can't use the theorem function, you have to create the statements of the theorems by hand. But then you can't later use the theorem function to prove them, in fact you are stuck. And moreover, with a complicated signature, it can be unclear whether or not those 'theorem's even have proofs in the signature! (Recall there is no user visible difference between a cell that states a theorem but has no proof, and a cell that states a theorem but has a proof buried 20 scroll-pages of cells later in the signature. (Or even a cell that states a theorem but has a cell later that looks like a proof but isn't actually a proof, as mentioned earlier.)) You could say, 'well, don't do that, only use things you've actually proven!' In which case I ask you, 'have you ever written a research paper like that, linearly from start to finish? you often need to write a bunch of statements to figure out how they best fit together (or indeed which ones you will need in the end, or indeed which ones are true) before it makes sense to go back and write in the proofs.' In any case, this is the actual situation we are in, that we need to write a bunch of lemmas, and only once we've figured out that the lemmas fit together to prove the theorems, does it make any sense to go back and push through the proofs of the lemmas.
-- What. At present there is only a single type of thing that exists in the signature. We believe there should be at least five types of things: Postulates/Axioms, DefinedCells, Definitions, Theorems, Proofs. (Of course, one can alias to allow Theorems to be called also Lemmas or Propositions or Corollaries (with no functional change).) There are reasons we write papers with these headers that distinguish information types, and we think globular will benefit from them.
Postulates/Axioms. These are cells that are assumed to exist. "Assume there is a 0-cell Blue. Assume there is a 0-cell Red. Assume there is a 1-cell from Blue to Red." (I'll use http://globular.science/1512.007 as a reference point.) At present, every cell is treated as a postulate (from a user's viewpoint---we don't know if internally globular already makes some distinctions).
Definitions. There should be definition types. So for instance, in our reference worksheet, "New Cup" is a 2-cell, and then there is an invertible 3-cell "New Cup Definition". (Woe be you if you forgot to name this cell properly, or if the name is too long that you can't see the "Definition" part at the end.) But in reality, we don't ever want to think about or use that 3-cell except as a substitution mechanism, much less use any of the higher invertible structure. Instead of two things in the signature (one 2-cell and one 3-cell), there should be just a single item in the signature, listed at the level of 2-cells [But this item can have two parts, the thing being defined, and the definition]:
"DefinedItem: CupBeingDefined ____Definition: [CupBeingDefined] := [OldCup with bump]"
Note: for this item (Definitions), it may be that the internal structure of globular doesn't have to change at all --- maybe this is 'just a UI issue', in the sense that perhaps you still want to be able to click on the [CupBeingDefined] 2-cell and have it in its compressed form, and then click on the 'definition' to expand the compressed picture into the uncompressed picture, much as it does at present. So perhaps all the request amounts to is that there be a definite link between a cell that is being defined and the cell that is the definition. And the suggestion is that the link should be that they are either part of the same item of the signature, or adjacent in the signature (perhaps with the definition indented subordinately to the thing being defined, as displayed above).
Remark: To aim for minimal changes to the UI (since I can only imagine what a nightmare UI issues are to implement), perhaps the different cell types can be distinguished simply by adding a little "A" [Axiom], "C" [cell being defined], "D" [definition of a cell], "T" [theorem], "Pf" [proof] in the lower right corner of the cell box, or something.
Theorems & Proofs. There should be cells with type 'Theorem', and there are two subtypes 'Proven', 'Unproven'. So you can create a 3-cell of type Theorem, and by default it is unproven (perhaps there is a "Tu" in the corner, or if you prefer you can gloss unproven theorems as 'conjectures'). So in our example, you create a cell (type Theorem-unproven) from the snake to the identity and call it "Theorem 1". This is aspirational, and there are no 4-cells yet.
Then you can prove the theorem by creating a 3-cell with the features: 1. has source the source of the theorem, 2. has target the target of the theorem, 3. is built from other preexisting 3-cells in the signature (whatever the type of those cells). Once this 'Proof' 3-cell exists, the type of the theorem cell changes from 'Theorem-unproven' to 'Theorem-proven' "Tp". Of course, it is proven modulo earlier cells, which may themselves be unproven.
But crucially, globular should maintain a graph of the dependencies of the theorem cells, and then it's easy to ask globular whether the graph of dependencies of every theorem cell bottoms out into axiom cells, or if there are some leaves that have type 'Theorem-unproven'. This is the core verification that is missing in the situation discussed in the "Why" section above.
As with the 'Cell defined' and 'Definition' being linked and displayed adjacently, the Theorem and its Proof should be linked and displayed adjacently. Again, this could be done as
"Theorem 1 ____Proof 1"
ie the Proof is subordinately indented to the theorem [and it's easy to see if there is no proof there] [and they are part of the same item of the signature].
Again, you might say it is useful to have the proof still exist as an n+1 - cell (as it does now), and I can see that, and see that it would require less internal change to the structure of globular to have it be so. So maybe the [Theorem+Proof] item in the signature is a pair of an [n-cell + (n+1)-cell], just like the [Cell defined + Definition] pair. If so, maybe the globular core encoding doesn't have to change, other than having a way to keep track of the linkages between [Cell defined] and [Definition] and between [Theorem] and [Proof], and to change the UI to reflect these linkages, and to allow [Theorems] that don't yet have [Proofs], [and to give every cell one of the five types], [and to have a way to see or at least query the dependency tree among the theorems].
I can imagine objections to this proposal, but anyway, that's the thought to consider/discuss.
In conclusion: globular is super cool.