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.

"Fortify": code formatter

The trunk/Fortify is an emacs-based Fortress code formatter. Fortress programs can be typed on ASCII keyboards and codes are automatically formatted by processing by LaTeX. For example, the following code: 

 sum: RR64 := 0 
 for k<-1:n do 
     a[k] := (1-alpha)b[k] 
     sum += c[k] x^k 
 end

is rendered as the following mathematical syntax:

Fortify example

Examples

The following Wiki pages include more examples of the mathematical syntax in Fortress:

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

Attachments