Fortress

Fortress was Sun Microsystems’ attempt to answer a blunt question: what would Fortran look like if it were designed today, by programming-language researchers, for machines with thousands of processors? The name was the answer in miniature - a “secure Fortran,” in the words of its specification, meaning “a language for high-performance computation that provides abstraction and type safety on par with modern programming language principles.” The same paragraph immediately adds that, “despite this etymology,” Fortress has “little relation to Fortran other than its intended domain of application.”

What Fortress actually became was stranger and more ambitious than a modernised Fortran. Its programs could be written in ASCII and rendered as mathematics; its for loops ran in parallel unless told otherwise; and its designers moved so much of the language into libraries - loops, reductions, even many operators - that the core became, in Guy Steele’s phrase, a “growable language.” It ran for nearly a decade as an industrial research project, produced an open-source interpreter and a substantial body of research, and was wound down by Oracle Labs in 2012.

History and Origins

The HPCS programme

Fortress was born inside DARPA’s High Productivity Computing Systems (HPCS) programme, which set out in the early 2000s to make supercomputers not just faster but easier to program. In July 2003 DARPA awarded Phase II contracts to three vendor teams: Cray ($43.1 million), IBM ($53.3 million) and Sun Microsystems ($49.7 million, for a system effort called Hero). Each team produced a new language - Cray’s Chapel, IBM’s X10, and Sun’s Fortress.

Fortress was designed by the Programming Language Research Group at Sun Microsystems Laboratories, led by Guy L. Steele Jr., whose earlier work includes Scheme, Common Lisp and the Java Language Specification. Steele’s own 2008 status report dates the HPCS-funded phase to 2003-2006; the authors of the 1.0 specification are Eric Allen, David Chase, Joe Hallett, Victor Luchangco, Jan-Willem Maessen, Sukyoung Ryu, Steele and Sam Tobin-Hochstadt, with further contributions credited to Joao Dias, Carl Eastlund, Christine Flood, Yossi Lev, Cheryl McCosh, Janus Dam Nielsen and Dan Smith.

A specification first

For nearly two years in public, Fortress existed only on paper. Version 0.618 of the language specification was downloadable from Sun Labs by late April 2005, and version 0.707 is dated 28 July 2005 - a 152-page document already describing traits, parallel loops, comprehensions and a type system that tracked physical dimensions and units. Steele presented the language’s approach to parallelism at PPoPP'06 in March 2006, and a 1.0 alpha specification appears to have followed later that year - its exact date is not documented, but commit messages show it existed by January 2007.

Losing DARPA, going open source

In November 2006, DARPA chose Cray and IBM for Phase III of HPCS. Sun was not selected, and government funding for Fortress ended. Sun kept the project alive and changed strategy: in early January 2007 it opened the Subversion repository of a prototype interpreter written in Java, released mostly under a BSD licence. The surviving source history opens on 4 January 2007, and the 1.0 beta specification followed on 6 March 2007.

Fortress 1.0

The Fortress Language Specification 1.0, dated 31 March 2008, was a turning point in an unusual direction: it made the language smaller. It was the first version “released in tandem with a compliant interpreter,” and to get there the team removed every feature the implementation could not yet support. Appendix F lists what was temporarily dropped, including:

• static checks and static type inference
• dimensions and units
• distributions (data placement across a machine)
• parallel nested transactions
• keyword parameters, type aliases, where clauses and coercions
• tests and properties
• syntactic abstraction

The front matter is candid that “most static checks in the implementation are currently turned off” and that all 1.0 beta features “remain goals for eventual inclusion in the language.” The payoff was rigour: every Fortress example in the 1.0 specification was a working program, executed on each test run of the interpreter and typeset automatically.

Wind-down

Oracle completed its acquisition of Sun in January 2010, and Fortress moved with its research group to Oracle Labs. Work continued on a compiler - the final source tree mixes 875 Java files with 74 Scala files and nearly 2,000 Fortress source files - but on 20 July 2012 Steele announced that the group was “winding down the Fortress project.” He wrote that “ten years is a remarkably long run for an industrial research project (one to three years is much more typical),” and identified the core obstacle as “the mismatch between the (rather ambitious) Fortress type system and a virtual machine not designed to support it” - a problem he said applied not only to the JVM but to every available VM. He also noted that Chapel, X10, Clojure and Scala had explored some of the same issues. The last commit in the preserved history is dated 31 August 2012.

Design Philosophy

A growable language

The specification opens by describing Fortress as “a general-purpose, statically typed, component-based programming language designed for producing robust high-performance software with high programmability,” and as “a ‘growable language’, i.e., a language that can be gracefully extended and applied in new and unanticipated contexts.” The phrase echoes Steele’s well-known 1998 OOPSLA talk Growing a Language, and Fortress was in many ways its practical test. Much of what other languages build into the compiler - the meaning of a for loop, of a summation, of many operators - Fortress defines in libraries, so that users and library writers can extend or replace it.

Code that looks like mathematics

Fortress’s most visible idea was that programs written by scientists should look like the mathematics they implement. Steele’s 2008 slides describe a “stylistic spectrum that runs from Fortran to Java - and sticks out at both ends”: more conventionally mathematical than Fortran, more object-oriented than Java.

Source code is typed in ASCII (or Unicode) and can be rendered in typeset form. The specification’s own example is the ASCII line

f(x) = x^2 + sin x - cos 2 x

which renders as f(x) = x² + sin x − cos 2x. Several conventions make this work:

• Juxtaposition is meaningful. Two numeric expressions side by side multiply; a function next to an argument applies it. 2 x is multiplication and sin x is a call.
• ASCII shorthands become symbols. Greek letter names turn into Greek letters (lambda → λ), and names like CUP, CAP and TIMES become ∪, ∩ and ×.
• Subscripts and superscripts are rendered. a[i] displays as aᵢ and ^ as a superscript.

The rendering was done by Fortify, an Emacs-based tool shipped with the distribution that converts Fortress source into LaTeX.

Parallel by default

The specification states it plainly: “for loops in Fortress are parallel by default.” Many other constructs are implicitly parallel too. The elements of a tuple are evaluated in separate implicit threads, as are the function and argument in a call, and the branches of an also do block:

do
  factorial(10)
also do
  factorial(5)
also do
  factorial(2)
end

A simple loop such as

for i <- 1:10 do
  print(i " ")
end

may print its numbers in any order - the specification’s own sample output is 5 4 6 3 7 2 9 10 1 8. Sequential behaviour has to be asked for. This reverses the usual default, where programmers write sequential code and the compiler or programmer later tries to find parallelism.

To coordinate shared state, Fortress provides atomic expressions - “executed in such a manner that all other threads observe either that the computation has completed, or that it has not yet begun” - and a tryatomic variant. The repository’s early history includes a January 2007 commit titled simply “Transactional memory,” and parallel nested transactions were among the features postponed for 1.0.

Key Features

Hello, World

A complete Fortress program, taken from the specification code examples in the project repository:

component HelloWorld
  export Executable

  run() = println("Hello, world!")
end

Components are Fortress’s unit of compilation and deployment. Exporting the Executable API makes a component runnable, and requires it to define run. Component source lives in .fss files and API declarations in .fsi files.

Objects and traits

Fortress is object-oriented, but without classes. Its two basic concepts are objects, which have fields and methods, and traits, which declare sets of methods - either abstract or concrete. The specification credits the formal analysis of traits to Ducasse, Nierstrasz, Schärli, Wuyts and Black. An object extends a set of traits, and traits may extend other traits, giving multiple inheritance of behaviour without inheritance of fields. Steele’s slides note that numbers, booleans and characters are all objects.

Overloaded functions are resolved by symmetric multiple dispatch on the runtime types of all arguments. Making that combination type-safe and modular, alongside multiple inheritance and generics, became one of the project’s main research threads.

Reductions, generators and comprehensions

Mathematical big operators are part of the syntax. The specification defines factorial as:

factorial(n) = PROD[i <- 1:n] i

which renders as ∏ over i from 1 to n. SUM works the same way, and a library writer can define new BIG operators. Underneath, a reduction calls a library-defined operator with a generator - an object that knows how to produce its elements, potentially in parallel - so the same mechanism drives loops, comprehensions and reductions.

Set and list comprehensions follow mathematical notation, with generators and filters on the right-hand side:

u = {x + y | x <- s, y <- t}
v = {x | x <- t, x >= 0}

Dimensions and units

The pre-1.0 specifications placed physical dimensions in the type system. The 0.707 specification’s example:

dim Length
unit m : Length
k = 1000
circumference = 40075 k m

The idea was that adding a length to a time would be a static type error. Dimensions and units were among the features dropped from the 1.0 specification pending implementation.

Arrays written as arrays

Array literals are laid out the way they look on paper, with whitespace separating elements and newlines or semicolons separating rows:

a : ZZ32[5] = [0 1 2 3 4]
b : ZZ32[2,2] = [3 4
                 5 6]

ZZ32 renders as ℤ32, the 32-bit integers, and RR64 as ℝ64, the 64-bit floating-point reals.

The Implementation

The reference implementation was an interpreter, and later a partial compiler, running on the Java virtual machine. The final README requires J2SDK 1.6 or later, Apache Ant and Bash, and gives “Solaris, Linux, Mac OS X, or Cygwin on Windows” as examples of suitable environments. By 2008 Steele reported a library of more than 10,000 lines of Fortress, covering big integers, rationals and intervals, collections, multidimensional arrays, sparse vectors and matrices, generators and reducers, and sorting. Community contributors outside Sun supplied an Emacs mode and a NetBeans plug-in.

The source history shows the arc of the project: 941 commits in 2007, a peak of 1,965 in 2008, then 1,099 (2009), 396 (2010), 588 (2011) and 408 in the final year. The original sites (projectfortress.sun.com, then projectfortress.java.net) are gone; the code survives in a GitHub mirror created in 2017.

Current Relevance

Fortress is a historical language. There have been no releases since the 2012 wind-down, and no maintained implementation or Docker image exists. Running it today means building the old Java code with an old toolchain from the GitHub mirror.

Its sibling HPCS languages had different fates: X10 continued at IBM until about 2019, and Chapel remains in active development. Fortress, the most ambitious of the three in its type system and syntax, was the first to stop.

Why It Matters

It took mathematical notation seriously. Fortress treated “write it the way it looks in the paper” as a core design requirement, not a cosmetic layer, and showed what that demands from a language: meaningful juxtaposition, Unicode operators, library-defined big operators, and a rendering pipeline as part of the toolchain.

It made parallelism the default. Parallel for loops, implicitly parallel tuples and arguments, and generator-driven reductions put the burden on programmers to request sequential execution. Steele’s ICFP 2009 talk drew a broader lesson from this work: data structures built for sequential traversal, like linked lists folded left to right, are a poor fit for parallel machines, and divide-and-conquer structures should replace them.

It is a case study in growability and its costs. Fortress pushed arguably more of the language into libraries than most statically typed languages before it, and paired that with symmetric multiple dispatch, multiple inheritance and generics. That combination produced real research - including the OOPSLA 2011 work on type-checking modular multiple dispatch - and also the type-system ambition that, by Steele’s account, no existing virtual machine could support efficiently.

It shows how to keep a specification honest. The 1.0 specification removed every feature the implementation could not run, and checked and typeset every example from real code. Few language specifications appear to have been held to that standard.