19.11.2014 Views

The Fortress Language Specification - CiteSeerX

The Fortress Language Specification - CiteSeerX

The Fortress Language Specification - CiteSeerX

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

An import statement either imports an API and allows the specified names (separated by commas) declared in the API<br />

to be referred to with their unqualified names:<br />

import {name + } from apiName<br />

or imports an API as another name:<br />

import apiName as anotherAPIName<br />

For convenience, an import statement can import an API and allow all elements declared in that API to be referred to<br />

with unqualified names:<br />

import * from apiName<br />

or can import an API and allow all elements except the specified names (separated by commas) declared in that API<br />

to be referred to with unqualified names:<br />

import * except {name + } from apiName<br />

If multiple elements with conflicting names are imported from separate APIs, all references to those elements within<br />

the component definition must be fully qualified. An export statement specifies the APIs that the component exports.<br />

Every component implicitly imports the <strong>Fortress</strong> core APIs; every fortress has at least one component implementing<br />

all of these APIs. A preferred component exporting these APIs (configurable by the user) is implicitly linked to every<br />

component installed in the fortress.<br />

An API (described in Section 22.3) serves as an interface of a component. For every API A exported by a component<br />

C, C must provide a definition for every program construct declared in A. <strong>The</strong>se definitions must match the declarations<br />

in A exactly; the modifiers on constructs, the types of variables, the headers of functions and methods, and the<br />

headers of traits must be identical. <strong>The</strong>re is one exception: A trait declaration with an empty comprises clause in A<br />

can be implemented by an object declaration in C. However, it is permissible for a trait or object definition to include<br />

additional methods and fields that are not declared in A. Also, a component is allowed to include top-level definitions<br />

that do not correspond to declarations in any of its exported APIs. <strong>The</strong> additional definitions that are not declared in<br />

A are not visible from outside the component.<br />

When a component is compiled, the APIs it refers to must be present in the fortress. <strong>The</strong> import statements in a<br />

component are not a way to abbreviate unqualified names of objects or functions. In our system, an import statement<br />

merely allows references to the imported API to appear in the component definition. References to elements of an<br />

imported API must be fully qualified unless they are imported by an import statement with a from clause. When a<br />

component imports a functional f (either a top-level function or a functional method) by an import statement with a<br />

from clause, the imported f may be overloaded with a functional f declared by the component. When a component<br />

imports a top-level declaration f from an API A, all the relevant types to type check the uses of f are implicitly<br />

imported from A. However, these implicitly imported types for type checking are not expressible by programmers;<br />

programmers must import the types explicitly by import statements to use them.<br />

A key design choice we make is to require that components never refer to other components directly; all external<br />

references are to APIs. This requirement allows programmers to extend and test existing components more easily,<br />

swapping new implementations of libraries in and out of programs at will.<br />

One important restriction on components is that no API may be both imported and exported by the same component.<br />

This restriction is required throughout to ground the semantics of operations on components, as discussed in<br />

Section 22.7.<br />

Every component has a unique name, used for the purposes of component linking. This name includes a user-provided<br />

identifier. In the case of a simple component, the identifier is determined by a component name given at the top of the<br />

source file from which it is compiled. A build script may keep a tally on version numbers and append them to the first<br />

line of a component, incrementing its tally on each compilation. <strong>The</strong> name of a compound component is specified as<br />

an argument to the link operation (described in Section 22.7) that defines it.<br />

164

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!