Advice and Suggested Guidelines

The following are some issues and considerations to be aware of when using the Notation Package and/or designing notations.

Build Up Notations in Stages

It is intrinsically difficult to debug something you cannot see; therefore, it is best to build up notations, seeing if something works or where a mistake has been made. It is harder to find errors if you enter a whole complex notation before testing it. Many notational problems will usually be revealed by examining the full form of an expression or its internal structure via Ctrl+Shift+E.

Do Not Alter Too Much

You should try not to alter too much. For example, changing commas to vertical separators is strongly discouraged. The more notational oddities present in the system, the higher the chance that one notation will adversely interact with another, giving unexpected results. Some parsers have mechanisms to detect conflicts in a given grammar, but the Notation Package does not.

Follow Existing Conventions Where Possible

Where possible, you should follow standard Wolfram Language conventions or follow the conventions of a given field. Inventing your own individual nonstandard notation is discouraged since such notations are necessarily unrecognizable to other users. Even if a notation has a historical origin and is not as intuitive as other possible notations the author could invent, it is usually better, where possible, to use the historical notation. Admittedly, however, it is sometimes difficult to resolve the inconsistencies present in a certain notation with the desire to have a uniform notation.

Parse without Evaluation Where Possible

When designing notations, it is desirable to be able to parse an expression to its correct full form without evaluation. This is not always possible for complex notations where there is no direct correspondence between an external form and an internal form. However, for the cases where it is possible, there should be no side effects from evaluation.

A common instance of unwanted evaluation comes from testing functions used in complex pattern matching. If possible, you should design testing functions to hold their arguments.

Internal and External Representations That Are Structurally Different

In cases where a conventional notation does not easily equate to an internal form in the Wolfram Language, it is suggested that you have the notation take the conventional form to the internal Wolfram Language name appended by "Typeset". For example, the MeijerG function should have the TraditionalForm

but the FullForm of the MeijerG function in the Wolfram Language has the following form.

MeijerG[{{a₁,…,a_n},{a_n+1,…,a_p}},{{b₁,…,b_m},{b_m+1,…,b_q}},ξ]

Therefore it is necessary to verify that the , , , and are numbers having the right values before it is even possible to construct the internal form of the MeijerG function. It is not possible to convert from the conventional form to the internal form without evaluation.

Therefore, in this case, we should take the traditional MeijerG box structure to a MeijerGTypeset[{{m,n},{p,q}},{a₁,…,a_p},{b₁,…,b_q}}]. Then evaluation takes this to the internal MeijerG function once it is has been established that it is possible to construct it.

Another possible case of this is taking a tensor defined using a GridBox to the expression TensorTypeset. Then evaluation takes this to an internal form Tensor, provided that the structure is valid, that is, the tensor does not have a contravariant and covariant index in the same column, etc.