Write a racket-friendly frontend for writing math equations #8

New Issue

2017-07-10T22:23:23+01:00

SuzanneSoy commented

2017-07-10 22:23:23 +01:00

(Migrated from github.com)

define-math-operator
define-math-variable
define-math-syntax
support for distinguishing Unicode and _ ^ subscripts and superscripts as separate from the "main" variable
Option to choose whether unbound math variables are allowed or not (with the possibility to declare temporaries easily), to catch typos and failed renamings.
Define rendering of operators, and automatically generate a parser from a simplified form of the notation. The parser can then be used (preferably when unbound variables are disallowed) to verify that all expressions in the document can be unambiguously parsed, given the operator precedence specified. If the operator precedence is also written in the document, as well as the definition of all operators (it should be possible to check this automatically), possibly as an appendix, then we can guarantee that a human reader should always be able to "parse" the formulas unambiguously. Note that we do not need to verify that the grammar is unambiguous, we only need to check that the equations as they are written can only be parsed in one way (or in equivalent ways, for operators which are declared as associative).

An equation in the source should look like this:

@$[∀ xᵢ ↦ κᵢ ∃ ρf ↦ (foo xᵢ)]

where ρf has been defined with define-math-variable to render as ρ_f, for example, and foo has been defined as a math operator with a specific rendering, and κ is also defined as a math operator which takes one mandatory subscript argument, in this case the ᵢ.

* `define-math-operator` * `define-math-variable` * `define-math-syntax` * support for distinguishing Unicode and `_` `^` subscripts and superscripts as separate from the "main" variable * Option to choose whether unbound math variables are allowed or not (with the possibility to declare temporaries easily), to catch typos and failed renamings. * Define rendering of operators, and automatically generate a parser from a simplified form of the notation. The parser can then be used (preferably when unbound variables are disallowed) to verify that all expressions in the document can be unambiguously parsed, given the operator precedence specified. If the operator precedence is also written in the document, as well as the definition of all operators (it should be possible to check this automatically), possibly as an appendix, then we can guarantee that a human reader should always be able to "parse" the formulas unambiguously. Note that we do not need to verify that the *grammar* is unambiguous, we only need to check that the equations as they are written can only be parsed in one way (or in equivalent ways, for operators which are declared as associative). An equation in the source should look like this: @$[∀ xᵢ ↦ κᵢ ∃ ρf ↦ (foo xᵢ)] where `ρf` has been defined with `define-math-variable` to render as `ρ_f`, for example, and `foo` has been defined as a math operator with a specific rendering, and `κ` is also defined as a math operator which takes one mandatory subscript argument, in this case the `ᵢ`.

Sign in to join this conversation.