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 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 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.
The following notation does not depend on evaluation in order to behave correctly.
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.
Internal and External Representations Which Are Structurally Different
In cases where 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
. 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
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
. 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
. Then evaluation takes this to an internal form
, provided that the structure is valid, that is, the tensor does not have a contravariant and covariant index in the same column, etc.