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
e.
Don't 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
Mathematica 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 an 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 when it is possible there should be no side effects from evaluation.
The following notation does not depend on evaluation in order to behave correctly.
Out[71]//FullForm= 
 

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.
The notation defined using the testing function StringNumericQ evaluates its arguments, which can lead to unpredictable results.
Out[72]=  

Internal and External representations which are structurally different
In cases when a conventional notation does not easily equate to an internal form in
Mathematica, it is suggested that you have the notation take the conventional form to the internal
Mathematica name appended by "
Typeset". For example the
MeijerG function should have the
TraditionalForm
But the
FullForm of the
MeijerG function in
Mathematica has the following form.
Therefore it is necessary to verify that the
m,
n,
p,
q 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_{1},...
,a_{p}},{b_{1},...
,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.