The Fortress Language Specification - CiteSeerX

More documents

Recommendations

Info

An import statement either imports an API and allows the specified names (separated by commas) declared in the API to be referred to with their unqualified names: import {name + } from apiName or imports an API as another name: import apiName as anotherAPIName For convenience, an import statement can import an API and allow all elements declared in that API to be referred to with unqualified names: import * from apiName or can import an API and allow all elements except the specified names (separated by commas) declared in that API to be referred to with unqualified names: import * except {name + } from apiName If multiple elements with conflicting names are imported from separate APIs, all references to those elements within the component definition must be fully qualified. An export statement specifies the APIs that the component exports. Every component implicitly imports the Fortress core APIs; every fortress has at least one component implementing all of these APIs. A preferred component exporting these APIs (configurable by the user) is implicitly linked to every component installed in the fortress. An API (described in Section 22.3) serves as an interface of a component. For every API A exported by a component C, C must provide a definition for every program construct declared in A. These definitions must match the declarations in A exactly; the modifiers on constructs, the types of variables, the headers of functions and methods, and the headers of traits must be identical. There is one exception: A trait declaration with an empty comprises clause in A can be implemented by an object declaration in C. However, it is permissible for a trait or object definition to include additional methods and fields that are not declared in A. Also, a component is allowed to include top-level definitions that do not correspond to declarations in any of its exported APIs. The additional definitions that are not declared in A are not visible from outside the component. When a component is compiled, the APIs it refers to must be present in the fortress. The import statements in a component are not a way to abbreviate unqualified names of objects or functions. In our system, an import statement merely allows references to the imported API to appear in the component definition. References to elements of an imported API must be fully qualified unless they are imported by an import statement with a from clause. When a component imports a functional f (either a top-level function or a functional method) by an import statement with a from clause, the imported f may be overloaded with a functional f declared by the component. When a component imports a top-level declaration f from an API A, all the relevant types to type check the uses of f are implicitly imported from A. However, these implicitly imported types for type checking are not expressible by programmers; programmers must import the types explicitly by import statements to use them. A key design choice we make is to require that components never refer to other components directly; all external references are to APIs. This requirement allows programmers to extend and test existing components more easily, swapping new implementations of libraries in and out of programs at will. One important restriction on components is that no API may be both imported and exported by the same component. This restriction is required throughout to ground the semantics of operations on components, as discussed in Section 22.7. Every component has a unique name, used for the purposes of component linking. This name includes a user-provided identifier. In the case of a simple component, the identifier is determined by a component name given at the top of the source file from which it is compiled. A build script may keep a tally on version numbers and append them to the first line of a component, incrementing its tally on each compilation. The name of a compound component is specified as an argument to the link operation (described in Section 22.7) that defines it. 164
Component equivalence is determined nominally to allow mutually recursive linking of components. By programmer convention, identifiers associated with components that are not included in the Fortress standard libraries begin with the reverse of the URL of the development team. A fortress does not allow the installation of distinct components with the same name. Component names are used during link and upgrade operations to ensure that the restrictions on upgrades to a component are respected, as explained in Section 22.7. Every component also includes a vendor name, the name of the fortress it is compiled on, and a timestamp, denoting the time of compilation. The time of compilation is measured by the compiling fortress, and the name of the fortress is provided by the fortress automatically. Every timestamp issued by a fortress must be unique. The vendor name typically remains the same throughout a significant portion of the life of a user account, and is best provided as a user environment variable. In our examples, we use published descriptions of packages in the Java 6.0 API [26] as examples of APIs expressible in our component system. We use, as names for these APIs, the names of the corresponding Java packages, with java replaced with Fortress. For example, the following is the beginning of a source file for a fictional application IronCrypto: component Com.Sun.IronCrypto import Fortress.IO import Fortress.Security export Fortress.Crypto . . . end 22.3 APIs Syntax: Api ::= api DottedId Import ∗ AbsDecl ∗ end AbsDecl ::= AbsTraitDecl | AbsObjectDecl | AbsFnDecl | AbsVarDecl | AbsDimUnitDecl | AbsTypeAlias | TestDecl | PropertyDecl AbsTraitDecl ::= TraitHeader (AbsMdDecl | AbsCoercion | ApiFldDecl | PropertyDecl) ∗ end AbsObjectDecl ::= ObjectHeader (AbsMdDecl | AbsCoercion | ApiFldDecl | PropertyDecl) ∗ end AbsCoercion ::= [widening ]coercion [StaticParams](Id IsType)CoercionClauses ApiFldDecl ::= ApiFldMod ∗ Id IsType ApiFldMod ::= hidden | settable | UniversalMod AbsVarDecl ::= VarWTypes | VarWoTypes : TypeRef ... | VarWoTypes : SimpleTupleType AbsDimUnitDecl ::= dim Id [default Unit] | (unit | SI unit ) Id + [ : DimRef ] | dim Id (unit | SI unit ) Id + AbsTypeAlias ::= type Id [StaticParams] APIs are compiled from special API definitions. These are source files which declare the entities declared by the API, the names of all APIs referred to by those declarations, and prose documentation. In short, the source code of an API 165
Page 1 and 2:
The Fortress Language Specification
Page 3 and 4:
4 Evaluation 36 4.1 Values . . . .
Page 5 and 6:
12 Functions 85 12.1 Function Decla
Page 7 and 8:
17.7 Coercions for Tuple and Arrow
Page 9 and 10:
IV Fortress for Library Writers 214
Page 11 and 12:
40.10The Trait Fortress.Core.Binary
Page 13 and 14:
Chapter 1 Introduction The Fortress
Page 15 and 16:
A note on the presented libraries i
Page 17 and 18:
component HelloWorld export Executa
Page 19 and 20:
foo:String → () baz: String → S
Page 21 and 22:
fortress upgrade Gary with Ralph No
Page 23 and 24:
halve(x : R64) : R64 = x/2 Predicta
Page 25 and 26:
while x < 10 do print x x += 1 end
Page 27 and 28:
It is also possible to convert a me
Page 29 and 30:
factorial(n) = ∏ i←1:n i This f
Page 31 and 32:
In both methods cons and append , t
Page 33 and 34:
default distributions will provide
Page 35 and 36:
Chapter 3 Programs A program consis
Page 37 and 38:
Chapter 10), a literal (see Section
Page 39 and 40:
(discussed in Section 13.13) to a s
Page 41 and 42:
Chapter 5 Lexical Structure A Fortr
Page 43 and 44:
U+0021 EXCLAMATION MARK ! U+0023 NU
Page 45 and 46:
If a character (or any other syntac
Page 47 and 48:
BIG SI unit absorbs abstract also a
Page 49 and 50:
escape sequences are useful for ASC
Page 51 and 52:
5.14.1 Multicharacter Enclosing Ope
Page 53 and 54:
Note: the elegant way to write Avog
Page 55 and 56:
• top-level variable declarations
Page 57 and 58:
declares id to be a mutable variabl
Page 59 and 60:
several new variables. This syntax
Page 61 and 62:
Chapter 7 Names Names are used to r
Page 63 and 64:
7.3 Qualified Names Fortress provid
Page 65 and 66:
Fortress also allows coercion betwe
Page 67 and 68:
• element types of a tuple type c
Page 69 and 70:
TypeAlias ::= type Id [StaticParams
Page 71 and 72:
‘}’. If such a clause contains
Page 73 and 74:
Note that a trait declaration inher
Page 75 and 76:
the parametric trait WrappedDiction
Page 77 and 78:
Chapter 10 Objects An object is a v
Page 79 and 80:
FldDef ::= FldMod ∗ Id [IsType] (
Page 81 and 82:
Chapter 11 Static Parameters Trait,
Page 83 and 84:
11.5 Operator and Identifier Parame
Page 85 and 86:
Chapter 12 Functions Functions are
Page 87 and 88:
swap(x :Object, y : Object) = (y, x
Page 89 and 90:
A function declaration may be separ
Page 91 and 92:
Chapter 13 Expressions Fortress is
Page 93 and 94:
Negating the literal 0 produces a s
Page 95 and 96:
the function is evaluated with the
Page 97 and 98:
13.10 Assignments Syntax: Expr ::=
Page 99 and 100:
treeSum(t : TreeLeaf) = 0 treeSum(t
Page 101 and 102:
Several common mathematical operato
Page 103 and 104:
The body of each iteration is run i
Page 105 and 106:
to the value of the condition expre
Page 107 and 108:
An atomic expression consists of th
Page 109 and 110:
13.26 Try Expressions Syntax: Flow
Page 111 and 112:
13.27.2 Static Expressions and Valu
Page 113 and 114: A = [1 2 3; 4 5 6; 7 8 9] then A 1,
Page 115 and 116: evaluates to the set {0, 4, 16} Map
Page 117 and 118: ignore(f x) is equivalent to: f x;
Page 119 and 120: trait CheckedException extends { Ex
Page 121 and 122: Chapter 15 Overloading and Multiple
Page 123 and 124: e called with. In other words, we e
Page 125 and 126: Chapter 16 Operators Operators are
Page 127 and 128: • “ordinary” operators: + −
Page 129 and 130: left context whitespace operator fi
Page 131 and 132: The rules below are designed to for
Page 133 and 134: 16.8.3 Enclosing Operators When use
Page 135 and 136: 16.8.9 Intersection, Union, and Set
Page 137 and 138: Chapter 17 Conversions and Coercion
Page 139 and 140: 17.3 Coercion Invocations One may i
Page 141 and 142: arguments nor with variable number
Page 143 and 144: trait B extends A end trait C exten
Page 145 and 146: a new coercion in a subexpression
Page 147 and 148: for tokens. For readability, plural
Page 149 and 150: Chapter 19 Tests and Properties For
Page 151 and 152: 19.5 Test Suites In order to allow
Page 153 and 154: Chapter 20 Type Inference Type infe
Page 155 and 156: 3. If a i is a functional applicati
Page 157 and 158: 21.2 Programming Discipline If Fort
Page 159 and 160: Here the call f(a, a) ends up setti
Page 161 and 162: 2. Ancestors, dynamically ordered b
Page 163: The ways in which fortresses are ac
Page 167 and 168: 22.5 Type Inference for Components
Page 169 and 170: Fortress.IO Fortress.Crypto IronLin
Page 171 and 172: execute(componentName:String, args:
Page 173 and 174: 3. If the replacement does not expo
Page 175 and 176: This method runs all test functions
Page 177 and 178: Fortress.IO Fortress.Crypto Fortres
Page 179 and 180: Part III Fortress APIs and Document
Page 181 and 182: 23.1.3 hash(maxval: N64): N64 23.1.
Page 183 and 184: opr =(self,other: Boolean):Boolean
Page 185 and 186: 24.1.20 getter hashCode(): N64 24.1
Page 187 and 188: False: BooleanInterval Uncertain: B
Page 189 and 190: 24.2.11 opr ∧(self,other: Boolean
Page 191 and 192: 24.2.19 possibly(self): Boolean 24.
Page 193 and 194: Chapter 25 Numbers 25.1 Rational Nu
Page 195 and 196: opr ⌈self ⌉: N realpart(self):
Page 197 and 198: 25.1.11 opr (self,other: Q):Boolean
Page 199 and 200: 25.1.26 floor(self): Z 25.1.27 opr
Page 201 and 202: Chapter 26 Negated Relational Opera
Page 203 and 204: 26.1.26 opr ⊀T extends BinaryPred
Page 205 and 206: 27.3 The Trait Fortress.Standard.Un
Page 207 and 208: Chapter 29 Dimensions and Units 29.
Page 209 and 210: unit secondOfAngle secondsOfAngle:
Page 211 and 212: Chapter 30 Tests 30.1 The Object Fo
Page 213 and 214: 31.2 Convenience Types An optional
Page 215 and 216:
Chapter 32 Parallelism and Locality
Page 217 and 218:
y evaluating the two elements of th
Page 219 and 220:
There is a DefaultDistribution whic
Page 221 and 222:
v = spawn at a.region(i) do a i end
Page 223 and 224:
expr ∑ type wrapper ∑ body R,
Page 225 and 226:
32.8.3 Using Overloading to Adapt G
Page 227 and 228:
Chapter 33 Overloaded Functional De
Page 229 and 230:
coercions: T U ⇐⇒ T ♦ U ∧
Page 231 and 232:
The More Specific Rule for Function
Page 233 and 234:
An infix/multifix operator declarat
Page 235 and 236:
may be so defined except ordinary p
Page 237 and 238:
and here some of these computed dim
Page 239 and 240:
unit name 1 name 2 name 3 : . . . u
Page 241 and 242:
Chapter 36 Support for Domain-Speci
Page 243 and 244:
Because syntax expanders are define
Page 245 and 246:
Part V Fortress APIs and Documentat
Page 247 and 248:
property ∀(a:T) ¬(a ∼ a) end A
Page 249 and 250:
trait PartialOrderOperatorsT extend
Page 251 and 252:
The HasMinimalElement trait specifi
Page 253 and 254:
The trait Commutative requires the
Page 255 and 256:
A value e is a left identity for a
Page 257 and 258:
trait ApproximatelyHasInverses T ex
Page 259 and 260:
end extends { ApproximateCommutativ
Page 261 and 262:
A default definition is provided fo
Page 263 and 264:
trait RationalQuantityunit U absorb
Page 265 and 266:
(self,other:RationalQuantityU,ninf
Page 267 and 268:
38.2.4 getter hashCode(): Z64 38.2.
Page 269 and 270:
Chapter 39 Components and APIs We d
Page 271 and 272:
Chapter 40 Memory Sequences and Bin
Page 273 and 274:
updatenat k(j: IntegerStatick, v: T
Page 275 and 276:
40.1.12 update(j:IndexInt, v: T): L
Page 277 and 278:
40.3.2 opr nat m[r:RangeOfStaticSiz
Page 279 and 280:
40.5 The Trait Fortress.Core.Binary
Page 281 and 282:
40.5.5 bit(m:IndexInt): Bit The res
Page 283 and 284:
40.6 The Trait Fortress.Core.Binary
Page 285 and 286:
40.6.4 opr nat m[r:RangeOfStaticSiz
Page 287 and 288:
40.6.16 opr ‖ nat m,bool bigEndia
Page 289 and 290:
countLeadingZeroBits():IndexInt cou
Page 291 and 292:
40.7.41 signedShift(j:IndexInt):T 4
Page 293 and 294:
40.8.6 signedDivide(other: T,overfl
Page 295 and 296:
littleEndian():BinaryEndianLinearEn
Page 297 and 298:
40.9.16 opr ‖ nat m,nat radix,nat
Page 299 and 300:
v: BinaryEndianWordb,bigEndianBytes
Page 301 and 302:
40.10.9 opr nat m[r:RangeOfStaticSi
Page 303 and 304:
40.10.24 splitnat b ′ () : Binary
Page 305 and 306:
itAnd(selfStart: IndexInt,source:T,
Page 307 and 308:
40.13.2 wrappingAdd(selfStart: Inde
Page 309 and 310:
40.13.30 unsignedMax(selfStart: Ind
Page 311 and 312:
40.13.55 gatherBits(selfStart:Index
Page 313 and 314:
Appendix A Fortress Calculi A.1 Bas
Page 315 and 316:
Values, evaluation contexts, redexe
Page 317 and 318:
Expression typing: p; ∆; Γ ⊢ e
Page 319 and 320:
α, β type variables f method name
Page 321 and 322:
Function/method name lookup: Fname(
Page 323 and 324:
One owner for all the visible metho
Page 325 and 326:
Traits defining a method: defining
Page 327 and 328:
Values, evaluation contexts, and re
Page 329 and 330:
Valid function declarations: p ⊢
Page 331 and 332:
Method definition lookup: visible p
Page 333 and 334:
Values, intermediate expressions, e
Page 335 and 336:
Field typing: p; ∆; Γ ⊢ vd ok
Page 337 and 338:
Appendix B Overloaded Functional De
Page 339 and 340:
Proof. We prove this for δ, but th
Page 341 and 342:
Upgrade A predicate upg? takes two
Page 343 and 344:
a is rendered as a foobar is render
Page 345 and 346:
• If a portion is sub and another
Page 347 and 348:
supercalifragilisticexpialidocious
Page 349 and 350:
any alternative names, with undersc
Page 351 and 352:
Appendix F Operator Precedence, Cha
Page 353 and 354:
U+007C VERTICAL LINE | | U+2016 DOU
Page 355 and 356:
The following two operators have th
Page 357 and 358:
U+003D EQUALS SIGN = = EQ U+2243 AS
Page 359 and 360:
U+22DD EQUAL TO OR GREATER-THAN U+2
Page 361 and 362:
U+2289 NEITHER A SUPERSET OF NOR EQ
Page 363 and 364:
F.4.8 Miscellaneous Relational Oper
Page 365 and 366:
U+21A5 UPWARDS ARROW FROM BAR U+21A
Page 367 and 368:
U+2224 DOES NOT DIVIDE ∤ U+2225 P
Page 369 and 370:
U+27F8 LONG LEFTWARDS DOUBLE ARROW
Page 371 and 372:
U+2960 UPWARDS HARPOON WITH BARB LE
Page 373 and 374:
U+29ED BLACK CIRCLE WITH DOWN ARROW
Page 375 and 376:
Appendix G Concrete Syntax In this
Page 377 and 378:
Extends ::= extends TraitTypes Excl
Page 379 and 380:
StaticParam ::= Id [Extends] [absor
Page 381 and 382:
Value ::= Literal | fn ValParam [Is
Page 383 and 384:
Appendix H Generated Concrete Synta
Page 385 and 386:
-> fn_decl -> object_decl -> var_de
Page 387 and 388:
-> id extends_opt absorbs_opt -> "n
Page 389 and 390:
-> w "excludes" w type_ref_list com
Page 391 and 392:
-> obj_decl_body_elem br obj_decl_b
Page 393 and 394:
-> op wr op_follows_op_w -> op wr e
Page 395 and 396:
-> no_space_op_expr_result no_space
Page 397 and 398:
id_opt -> -> w id with_opt -> -> w
Page 399 and 400:
-> unpasting_elem rect_separator un
Page 401 and 402:
-> "}" comprehension -> set_compreh
Page 403:
-> do_expr -> for_expr -> spawn_exp
Page 406 and 407:
-> type_ref -> "(" w type_ref w ","
Page 408 and 409:
enc -> enc_literal op_or_enc -> op
Page 410 and 411:
Bibliography [1] O. Agesen, L. Bak,
show all

The Fortress Language Specification - CiteSeerX

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?