Fortress

Link: http://www.ibm.com/developerworks/wikis/display/woolf/Fortress

 

Added by bwoolf, last edited by bwoolf on Oct 26, 2006  (view change) 窗体顶端 Labels:  (None)窗体底端

 

Fortress

In "A Growable Language" at OOPSLA 2006, Guy Steele of Sun Microsystems Laboratories spoke about the Fortress programming language.

 

Fortress is based on a premise that a planned programming language takes too long to develop and is obsolete by the time it's available. To combat this, a programming language cannot be designed, it must be grown. Thus a focus of the Fortress language is to make a very simple language that supports the development of powerful class libraries, and allow the innovation to occur in the class libraries. In this way, the language can grow and adapt to new uses by updating the class libraries.

Fortress is intended to replace FORTRAN for developing mathematically intensive applications. One consequence is that the main programming notation is mathematical equations. The equations can be entered as ASCII using wiki-like markup, and displayed like the equations shown in textbooks, which is a very natural language for the intended audience of mathematicians and scientists. Fortress will have mathematical data types like matrices and support matrix multiplication.

Fortress has built-in capabilities to divide a program into parts to process them concurrently and distribute them across multiple processors, capabilities that are very important for rapidly calculating complex equations. One such opportunity is a loop: Why run a loop ten times in one thread on a processor if you can run it once on ten different processors concurrently? So Fortress tries to do this dynamically at runtime; this enables you to write code one way that will adjust to the hardware available at runtime. The language uses constructs called generators to perform the evaluation, which are like iterators on steroids. In some equations, loops must be run sequentially, perhaps because the result of one iteration is used as input to the next. In this case, one marks the loop as "seq" in the source code, which selects an appropriate generator at runtime.

Most (all?) of these mathematic specifics is handled in the class libraries, not the language itself. Thus it should be possible to use the language to write and run different class libraries for domains very different from mathematics, and handle those domains in an equally natural manner (depending on the capabilities of the libraries). Because the language is already written, developing new class libraries for new domains should be much faster and less error prone than developing a new language from scratch. These new domains should still be able take advantage of the language features, such as transparent runtime access to parallel processing.

A Growable Language

Link: http://www.oopsla.org/2006/program/sessioninvitedspeakers/dr._guy_steele.html

I gave a talk at the 1998 OOPSLA called "Growing a Language" (sometimes remembered as "the words-of-one-syllable talk") in which I suggested that programming languages have become such complex artifacts that they cannot be designed all at once; rather, they must grow over time. Therefore, programming language designers should plan for such growth, along with the growth of a user community. Moreover, language growth may be more effective if the growing user community can participate.

This raises an interesting technical question: how might the explicit goal of planning for growth over time affect the design of a programming language?

The Fortress programming language project at Sun Microsystems Laboratories has three principal design goals: to promote the expression and use of multithreaded parallel algorithms; to support a large variety of syntactic notations, including (as far as possible) standard mathematical notation as used to specify scientific computations; and to allow the language to grow and to be extended by the user community. (This work has been funded in part by DARPA through their program for High Productivity Computing Systems.)

The Fortress design team has followed a key strategic design principle: whenever we consider adding a feature to the language, we ask whether it might better be provided by a library routine, written in Fortress source code, so that it can be modified, extended, or replaced by others. To this end, we have incorporated rather elaborate mechanisms for encapsulation and abstraction, including composable components and a parameterized polymorphic object-oriented type system. The result is that we have a fairly complicated language for library writers that enables them to write libraries that present a relatively simple set of interfaces to the application programmer. Thus Fortress is as much a framework for language developers as it is a language for coding scientific applications. We find ourselves using objects and traits extensively within the libraries in order to present to the programmer a scientific application language that is formula- and array-oriented.

Biography: Sun Fellow Guy Steele is a researcher for Sun Microsystems Laboratories, working on the Programming Language Research project. His research interests include Algorithms, Compilation, Distributed Systems, High Performance Computing, Java, Lisp, Scheme, Object Oriented Programming, Operating Systems, Programming Languages, Software, and Supercomputer design.