Mathematical Syntax in Fortress

One of Fortress's goals is that programs (efficient programs) can look like mathematics and be more concise and readable. This is not an original goal, but several new developments make it more likely to succeed. Unicode provides a standardized encoding for many mathematical glyphs that were otherwise platform and tool-dependent. Parsing is not nearly as solved and dead as many people think; parsing Fortress is hard, but packrat parsers provide enough flexibility and modularity to make it tractable. The development of and widespread use of wikis makes the use of a sort of ASCII creole more acceptable for expressing formatting in the absence of sophisticated formatting interfaces.

Unicode

Unicode provides a large collection of mathematical operators; these can be found in the code tables Mathematical Operators, Miscellaneous Math Symbols-A, Miscellaneous Math Symbols-B, and Supplemental Math Operators. Support for the full collection of symbols is not widespread yet, but three fonts offer good coverage:

  • Code2000 many characters, shareware ($5)
  • Everson Mono monowidth, shareware (€25 for 3 computers)
  • Stix fonts comprehensive, integrated with TeX, probably released later this year.

Precedence (or lack of it)

It's a safe bet that there are is no widely-known set of precedences applying to the full collection of Unicode mathematical operators. Fortress very conservatively defines precedence where it is "obvious" (to Fortress designers), and otherwise does not. Furthermore, the parsing precedence relation is 'not' transitive:

  • + binds tighter than <
  • < bind tighter than
  • but there is no precedence defined between + and ; 1 + 2 ∧ true is simply a parse error.

Space-sensitive parsing

Space-sensitive parsing helps with several problems encountered. The first is that some operators have more than one use; for example, "-" can either appear as prefix or suffix; "|" can either appear as an infix or enclosing (absolute value) operator. It's also possible that a programmer would not be entirely sure of the precedence of some Unicode operators; using the convention that wide spacing implies low precedence, a programmer can show what is intended.

Add more errors

If the spacing in an expression implies a different precedence than is actually defined, it is an error. Thus

 1+2 ⋅ 3

is an illegal Fortress expression; it is confusing, and/or indicates that the programmer expects a different evaluation than will actually occur.

Wiki-like legacy input syntax