Chapter 8: Name spaces

8.1 : Scopes

A symbol's meaning is given by the context in which it appears. A particular meaning (for example: ``n is the second parameter in the definition of the `+' function in the domain Integer'') has a visibility, or scope, governed by the constructs in which it is introduced. In common with most programming languages, Aldor mainly uses lexical scoping.

New scopes in Aldor are introduced by the following expressions:

• E where Definitions
• +->
• with
• add
• for i in...
• Applications, e.g. Record(i: Integer == 12)

These forms may be nested to any depth. Note that the last two bind names in particular positions in the expression, and do not form general scope levels.

Lexical scoping implies that the only variables visible at a given point in a program are those that have been created locally or imported into scopes surrounding the current point.

In Aldor, there are two types of meaning for a given symbol --- it must either be a constant or a variable. Constants are created in the following ways

• "==" statements.
• The bound symbols in a "for" iterator
• implicitly via an "import" statement
• implicitly via a declaration

A constant may not be assigned to, and therefore holds the same value throughout its lifetime. If two constants have identical names in the same scope (the name is overloaded), then an assigned variable's type or a qualification (using $) is used to disambiguate the uses of the constants.

A variable may be created explicitly, by a declaration, or implicitly, when it appears on the left of the assignment operator, ``:=''. Variables may be re-assigned; they may not be used in type-forming expressions.

When a scope forming expression is used in Aldor, all definitions and declarations directly within that scope are visible throughout the scope --- sequences have no effect on what names are in scope. In the example

...
{
  x: Integer := 4;
  y: Integer := 3;
}
adds(a: Integer): Integer == x + a + z;
z: Integer := 3 + y
...

the current scope is extended with the variables x, y and z along with the constant adds. Note that adds uses z before it is defined in the outer sequence, and that x and y are defined in a subsequence, but the definitions are at the same scoping level as the others in the example.

A type may be viewed as an environment, mapping constant names and types into value bindings from a particular type. In Aldor, object files and libraries are values which map names and types into the values defined inside the file or library. This idea allows types, object files and libraries to be treated uniformly.

8.2 : Constants

A constant definition may appear at almost any point in a program. If its outer defining scope is a with or add then it will be treated as an export of that type. If the type is used in a context not requiring the export, then the export will not be visible when the type is imported. A definition returns the type of the new variable.

A particular name in a scope may be overloaded with several constant values, either defined in the local scope or imported into it.

#include "aldor"
x: Integer == 3;
x: String  == "hello";
print << (x+x)       << newline;     -- uses x: Integer
print << concat(x,x) << newline;     -- uses x: String

Here the name x refers to both a constant of type String and a constant of type Integer. In the two print statements, the constant to be used is selected according to context --- the first requires an Integer, while the second requires that x must have a ``#'' operation, which implies that the String constant is used.

8.3 : Disambiguators

Occasionally, it is not possible to tell which constant to use given a particular name. For example

x: String == "Hi";
x: List Integer == [1,2,3];
a: SingleInteger := 1;
print << x.a << newline;

print << (x.a)@Character << newline;

Sometimes a constant with the same name and type may be imported from different domains. In this case the package call operator, $, can be used to disambiguate the constants. For example, both Boolean and SingleInteger export a constant ``#'' which is an integer storing the number of possible values of the domain. Thus

print << #$Boolean       << newline;
print << #$SingleInteger << newline;

will print 2, and then a number 2ⁿ, for some n depending on the host machine.

8.4 : Import from

The ``import'' statement brings constants which are exported from types into scope. The simplest form of an import statement is

import from D1,..., Dn;

8.5 : Inline from

The ``inline'' keyword is similar to the ``import'' keyword, but instead of importing names into a scope, it allows the result of compiling the current scope to depend on the compiled values of the constants indicated. This dependency information may then be used by the compiler to determine if a particular function may be inlined (for optimization) instead of called in the normal way. Allowing this form of optimization can give very high quality code. The cost is that, if a file is recompiled, then every file which contains an inline statement mentioning that file should also be recompiled to ensure consistency, slowing down the development cycle.

#library Aldor "aldor"

import from Aldor;
import from Integer;
import from DoubleFloat;
import from TextWriter;         -- For `print' and ...
import from Character;          -- for `newline' and `<<'
                                -- (all normally imported
				-- when `aldor' included).
inline from Integer;

print << 3 + 2     << newline;  -- 3 + 2 gets optimized.
print << 3.0 + 2.0 << newline;  -- 3.0 + 2.0 doesn't.

8.6 : Variables

New variables are created by declaration statements (described below), or implicitly by the first assignment to a variable inside a scope. In the implicit case, the variable is lexical and local to the scope.

It is an error to have two variables with the same name in the same scope---thus

x: Integer := 3;
x: String  := "hello";

will give a compile-time error ``Variables cannot be overloaded''. In addition, it is an error to define a constant with the same name as a variable within a scope. An assignment will create a new variable hiding any names not explicitly imported. For example:

import from Integer;

+: Integer := 3;

defines a new variable of type Integer. The ``+'' function from the domain Integer is hidden by this statement --- it can still be accessed by using the qualified name: +$Integer.

Aldor will generate a warning if an implicitly local variable in a new scope shadows a similarly named variable in an outer scope.

8.7 : Functions

A function introduces a new scope level which includes the parameters to the function: As you might expect, parameters to the function are visible inside the function. A function expression has the following form:

(s1: S1 == v1, ..., sn: Sn == vn) : (t1: T1, ..., tm: Tm) +-> E

8.8 : Where

A ``where'' expression is of the form:

Expr where Defns

in which Defns is a sequence of declarations and definitions, used in the evaluation of Expr. For example

x+y where { import from Integer; x := 2; y := 3}

evaluates to 5. This can be useful when an expression has many repeated parts which can be factored out as a sequence of definitions. The names introduced in the declarations are visible in the expression part and also in the declarations (note that this expression does not import bindings from Integer into the outer scope). However, names introduced in the Expr are treated as if they are declared at the outer scope level, so

x: Integer == y where { import from Integer; y := 2}

adds a variable ``x'' to the outer scope, the definition of which references ``y'' which will not be visible in the outer scope.

8.9 : For iterators

8.10 : Add

The ``add'' operator has the following syntax:

Add-domain add declarations

8.11 : With

A ``with'' expression forms a new category, and has the following syntax:

L with R

This is equivalent to

with { L ; R }

8.12 : Application

Applications allow arguments which are declarations or definitions. The identifiers which are declared or defined in arguments are then local to the application form. For example, in

F(3.2, 5.8, tolerance == 0.02)
G(T: Type, List T),

the identifier tolerance is local to the application of F, and the identifier T is local to the application of G.

A comma expression may declare identifiers to be used in later elements. In the expression (e₁,..., e_n), if any e_i is a declaration or definition, then the name is visible in the expressions e_j, i < j <= n. The declarations place names in the current scope --- the comma expression of itself does not create a new scope. So, in the case where a comma expression provides arguments to a function, declared identifiers are local to the application.

This allows dependent function types to be created: the -> operator is simply a function which is applied to two tuples of types. For the expression (S₁,...,S_n) -> T₁,...,T_m) any identifiers declared in S_i are visible in any of the T_j. In addition, both the left and right hand sides are comma expressions, so the above rules apply.

The following is a possible example of the use of dependent types to form a new function type:

f: (T: Type, t: T) -> (LT: Aggregate T, lt: LT)

Note that ``T'' is used on both sides of the arrow.

It is similarly possible to create dependent product types: the Cross operator is a function which accepts some number of types as arguments and produces the product type. The argument types may have declarations which induce dependency. For instance:

Cross(T: Type, List T)

While the built-in functions ``->'' and ``Cross'' allow dependency inducing declarations as their arguments, the language does not currently provide a mechanism for creating new functions that support this. Thus, although

HashTable(n: Integer, IntegerMod n)

is a legal call, HashTable cannot support this form of dependency, and an error may be signalled by the compiler when this type is used.

8.13 : Declarations

Declarations associate a type with a name. A declaration is of the form:

modifier idlist: Type.

The modifier is one of:

• default
• define
• local
• fluid
• free
• export

Either (but not both) of the modifier and the ``:Type'' may be omitted. A declaration may appear in any context not requiring a value, and remains in force throughout the enclosing scope. If the modifier is omitted, the compiler assumes that local is meant and issues a warning that default may be intended.

Some modifiers allow definitions or assignments in a declaration. In this case, the type part is optional and the declaration has one of the forms

Modifier id [: Type ] := E

Modifier id [: Type ] == E

If the type information is omitted, then the type is inferred or taken from default declarations. When the type information is present, say declaring id: T, the declaration also imports type T into the current scope. If this is not desired, then the declaration may use ``:*'' in place of ``:'' to avoid the import.

Finally, it should be noted that it is also possible to give a sequence of assignments or definitions in these statements. For example,

local {
        a: Integer := 1;
        b: Integer := 2;
        c: Integer := 3
}

Default

The ``default'' modifier declares that any instances of the names specified will have the type indicated. This does not create any new bindings.

default n: Integer;
n := 23;
f(n): Integer == n + 1;
print << n^10 << newline where { local n := 2 };
print << n    << newline;

8.14 : Fluid varaibles

Fluid variables are not often needed but can be useful when a large amount of dynamic state is needed, or a routine is parameterized by a very large number of variables.

A fluid variable exists throughout the lifetime of a program, and its value is always the most recent extant binding of the variable. The extant bindings are the bindings of the variable inside fluid declarations from scopes which have not yet been exited.

When a variable is declared fluid, all references to that name inside the declaration's scope are assumed to be fluid.

An example might help:

#include "aldor"

fluid n: Integer := 2;

f(): () == print << "The value of n is " << n << newline;
g(): () == { fluid n := 3; f() }

f();
g();

The fluid variable ``n'' is bound at the top-level and given the value 2. This is the value printed by the top-level call to f. In the next call, the function g re-binds n giving it the value 3. Then when f is called, it is the new value, 3, that is printed. On exit from g, this binding of n is removed and n assumes the value it had in the outer scope.

As usual, an inner declaration (e.g. local, export) may locally over-ride an outer declaration (e.g. fluid). Note that without the ``fluid'' declaration in g, the inner n would be treated as having an implicit ``local'' declaration. This would then behave as in the example below. The inner occurrence of n is a new local variable, unrelated to the outer n, and the call to g results in 2 being printed.

#include "aldor"

fluid n: Integer := 2;

f(): () == print << "The value of n is " << n << newline;
g(): () == { local n := 3; f() }

f();
g();

If no initialization is given in the fluid declaration, then the variable is taken to exist in an outer dynamic scope. In the example below, the function ``g'' provides a binding for the variable ``n''. Then, when the function f is called from g, the uses of ``n'' in f refer to the binding in g.

#include "aldor"

f(): () == {
         fluid n: Integer;
         print << "The value of n is " << n << newline;
}
g(): () == {
         fluid n: Integer := 3;
         f();
}

g()

If an assignment to an existing fluid variable occurs in a context other than a fluid declaration, it will modify the current value of the variable, rather than creating a new one:

#include "aldor"

fluid n: Integer := 2;

f(): () == print << "The value of n is " << n << newline;

g(): () == {
        fluid n: Integer;
        n := n + 1;
        f()
}

g();
g();

A file may use fluid variables which have been bound in other files, but no type information regarding these variable is known, so it is the programmer's responsibility to ensure that the types match.

In the current implementation of Aldor, a fluid variable must have a binding point at the top level of some file. It is an error to have two fluid variables of the same name and different types in a program.

The current syntax for rebinding fluids --- using assignment inside a fluid declaration --- may be changed in future.