Wikiproofs:Syntax Discussions

There's a discussion on syntax threaded through Wikiproofs:Tearoom. I think it's a very important discussion to have, and is especially relevant for resolving some of the divergence between Ghilbert and JHilbert. I think it would be reasonable to refactor some of the discussion in the Tearoom over here, so it's more coherent. On to substance...

I agree with much of what Mellocat has written, particularly that it makes sense to store presentation information separately from low-level proofs.

I'd go even further, though, and say that while it is essential for the low-level layer to be unambiguous, it is not actually necessary for the presentation layer to be. Ordinary mathematical notation is quite ambiguous in a number of ways, most notoriously "...", which is said to mean "guess what goes here."

One reason to separate presentation is that the same underlying operation will have different representations depending on context. Thus, a development of functions in set theory (a la Takeuti and Zaring) will represent function application as, where in most applications it should be written F(A), or, in special occasions, sin x. Similarly for other primitives such as multiplication, which should be represented as · when developing the theory, but should usually be written as concatenation in applications. I think the best solution is to have the same low-level representation in all cases (so theorems can be shared), but varying presentation.

This is prelude to an assertion I'd like to make, and would love to have discussed in detail: the decisions I've made regarding syntax in Ghilbert are good enough. In particular, prefix S-expressions made of ASCII are preferable at the low level to fully parenthesized expressions with Unicode symbols. The choice of ASCII means that we don't have to worry about Unicode canonicalization or normalization just to determine whether two identifiers are identical. (This will require likely require more code than the Ghilbert proof verifier and also be subject to change as Unicode continues to evolve; see .) The question of prefix vs infix is more a matter of preference; I like the simplicity of always knowing that the term name is at the beginning, and I also like not having to count parentheses at the beginning of a term. But the main point is that it doesn't really matter, as most users not working on the internals will see a pretty presentation, which will be the same whether the low level representation is prefix or fully parenthesized infix.

If people haven't played with the prototype app, or at least seen a screenshot, I recommend it. There's plenty more fine-tuning I'd like to do on the presentation, but again I feel pretty strongly it's good enough. I haven't yet started on parsing the human-friendly math representation on the input side, but that's a pretty clear next step after I get the spec nailed down some more and have the web-app interaction more usable (I'd like to have, at least, the ability for one person to pose a theorem as a problem and another to enter a proof). Again, my assertion is that, if there is going to be a good presentation layer, then compromising the simplicity and unambiguousness of the low-level representation layer is a bad thing.

Discussion is more than welcome!

Raph 22:24, 28 March 2010 (UTC)


 * I have a hard time reacting to a long-term vision, so I'll start with the prototype at . It seems to require that I have quite a bit of interaction with the ASCII. Having expressed my aversion to ever seeing the ASCII, I'll also express scepticism about writing proofs in a jsmath-like/MathJax-like/fancier-javascripty math typesetting system. I'm willing to be convinced otherwise, but, well, it just might be a matter of distrusting things which don't exist yet or it might be a doubt that the typesetting would really stay out of the way. My vision is something like what we now have on wikiproofs, augmented with something like:


 * precedence


 * the ability to have the operator split across more than one token. For example,   would be syntactic sugar for ,   would be syntactic sugar for  ,   would be syntactic sugar for  , etc (I guess this is sort of like smalltalk keyword arguments).  I don't know exactly how general this mechanism could be made and still coexist with precedence, but I'm hoping for some kind of middle ground between (a) austere syntaxes like s-expressions, (b) syntaxes which hardcode the operators and precedences, like ruby/C++/etc, and (c) highly configurable syntaxes where parsing becomes really complicated (HOL? I don't know it well enough to say whether it is an example of this or not).

Whether this is the only syntax, or whether others exist (for example for interchange with other systems), I don't think I have much opinion about. I'm just making a statement about what I envisage interacting with as I write proofs. Kingdon 23:36, 27 July 2010 (UTC)