Workspaces and Scripts

Parsing Rules for A+ Script Files

A+ script files are parsed from top to bottom when loaded, and all unresolved names are assumed to be variables. For example, suppose the following two lines appear in a script, in this order:
f{x}:g  x
g{y}:y,' '
When this script is loaded, the definition of the function f is parsed before that of g, and therefore g is assumed to be a (global) variable in the definition of f, and the symbol is taken to be the dyadic primitive. Then the definition of g is parsed and it is determined that g is a function. When f is evaluated, a type error results because the dyadic primitive is passed a function as a left argument.
 : type
*     x         Inquire about x
 `sym            It's a symbol.
*     {g}
 `func           But g is a function.
This problem could have avoided by defining g before f. In general, however, and certainly in large applications, it is not reasonable (and sometimes not possible) to maintain scripts so that functions are always defined before they used. The problem could also be avoided by using the alternate function-call syntax; in the above example:
     f{x}:g{ x}
Now the A+ process can tell from the syntax that g is a monadic function, whether or not it has been defined. This syntax is unambiguous, whereas that of f in the original definition is ambiguous.


   Expression Continuation in Entry and Function Definition

When an expression, expression group, or function definition is entered on several lines in an A+ session, A+ supplies stars at the left of each line to indicate the depth of punctuation. In general, these stars are used to indicate the total number of open quotation marks (at most one), braces, and parentheses, and an expression or function definition remains open until they are closed. Brackets are not treated in this way, however, and in the absence of an open quote, brace, or parenthesis a line or series of lines with an open bracket elicits an error message. Pressing the Enter key while inside a quotation mark inserts a newline character in the quoted string, but pressing Linefeed causes A+ to ignore all entries on the current line that follow the open quote (including the Linefeed itself).

If any brackets, braces, or parentheses are open when a function definition is closed, a token error is reported and the definition does not take effect. At the time when such punctuation becomes isolated (e.g., after the closing parenthesis for the bracket in (3 4;bd[1;3)),  a message "Mismatched parentheses" (no matter what the punctuation - brackets, braces, or parentheses!) appears at the bottom of the screen in Emacs.

The expressions case(target) and if(condition) and while(condition) are each followed by an expression or expression group in actual usage, but they are considered by the parser to be complete (with a Null as the following expression) when they are followed by the Enter, so don't break a line there unless you have something else holding the expression open, and don't immediately follow an if(condition) with an else with the intention of returning and filling in the if action unless you are very sure you won't forget.

Function definition has one continuation peculiar to itself: if the Enter key is pressed immediately after the colon following the function header, the function definition remains open, for just one more line (unless that line produces a continuation). If anything, however, even just a space, is entered after the colon, then there is no implied continuation. In particular, if only spaces are entered after the colon, a parse error is reported and the opening of the definition has no effect.

   Expression Groups for Immediate Execution

In immediate execution, when there is no pending punctuation or function definition, several expressions can be entered on one line, separated by semicolons. They will be treated as an expression group. The next section discusses the implications of this treatment for display.

One useful aspect of this treatment is that one can bring into the workspace for immediate execution a script line which is only part of an expression group. Putting it another way, an expression group or part thereof can be brought in and executed immediately as long as its punctuation is matching - as long as it contains either both or neither of the group's enclosing braces.

An expression in braces, with no semicolon, also constitutes an expression group.

   Immediate Execution Display

When an expression or expression group is entered for execution, by pressing the Enter key, an error message may be displayed. If it is not, then the result is displayed, except that it is not displayed for an expression whose last operation is Assign.

The display of the Null is indistinguishable from no display, so in effect the displaying of the result can be suppressed for an expression or expression group by appending a semicolon to it, making the expression a courtesy expression group. Likewise, display can be forced for an expression alone on a line, even when it ends with Assign, by preceding the expression with a semicolon. (Preceding such an assignment in immediate execution by a , thus applying Print to it, causes it to be displayed twice, once by Print and once as the default display of an expression whose last function is not Assign.)

For function and dependency definitions, there is no additional display: the entered definitions, together with the A+ prompts indicating depth of punctuation, are the entire displayed response.

   Default Display of Arrays

Arrays are listed in ravel order. Simple character arrays start at the left margin. Simple numeric arrays are indented one space. Numbers that are in columns in the display are aligned. Simple vectors are displayed horizontally. Simple arrays of higher rank are displayed with vertical columns, horizontal rows, one skipped line between cells of rank 2, an extra skipped line between cells of rank 3, and so on. For example:
     2 2 2 6
  0  1  2  3  4  5
  6  7  8  9 10 11

 12 13 14 15 16 17
 18 19 20 21 22 23

 24 25 26 27 28 29
 30 31 32 33 34 35

 36 37 38 39 40 41
 42 43 44 45 46 47
A < is used for a function scalar, since it must always be shown as an enclosed function expression. Furthermore, vectors of function scalars are displayed vertically. For example:
<  +          Vector displayed vertically, with < showing enclosure of the
<  -          function expressions, to make simple, depth-0 function scalars.
<  =

Each nested component of a nested array begins on a new line. A < character is used to indicate the beginning of an enclosed object. It is also used sometimes to indicate a symbol, as shown above, but it is not so used in this manual except for that example. For instance:

     (1 2 3; 2 225; (3 4;2 3;<<100))
<  1 2 3
<  25 25
   25 25
< <  3 4
  <  0 1 2
     3 4 5
  < < <  100

   Resuming Execution

When execution of a expression or function has been suspended because of an error or an interruption, expressions can be entered for immediate execution. (The expressions may include calls of other functions and may lead to suspensions of their own.) Values, shapes, types, etc. of both global variables and ones local to the suspended function may be examined and changed. The arguments on the stack (&0 &1 ...) can also be examined and changed. (Changing variables which were arguments to the suspended function has no effect on the stacked arguments.)

To resume execution of the suspended function, with the workspace size increased if necessary, enter
alone on a line.

To abandon execution, and execution of any pendent function that is waiting on this suspended function, enter either
alone on a line.

To abandon execution of the last n suspended functions, enter
     $reset n
and to abandon execution of all suspended functions, enter just
See the
Reset command.

   The Form of Error and Other Messages

Error reports are prefixed by a comment symbol and the type of report in brackets, to make it more explicit and also to prevent it from spoiling a part of a log that would otherwise be usable as a script:
[error]  : domain
[error]  segv
 PKG: 1: Storing .two      See the package example.
There are, however, some error messages that are not in this form, none of them strictly A+ error messages. Among them are
filename: No such file or directory
not an `a object
and a great many messages from adap.


To help in avoiding name conflicts, A+ provides contexts. A context provides a level of qualification for global names. The fully qualified form of any global name is c.x, where x is the unqualified name of the object and c is the context for that name. Every name is accessible from every context by the use of its fully qualified form.

The workspace always has one current context. Initially, at the beginning of an A+ session, it is the root context, whose name is the empty string. So .y is the form that a fully qualified name takes in this context. Such a name always refers to the root context. The current context can be changed by  $cx cxt  as discussed for the Context command; by convention, $cx .  is used to change the current context to the root context - i.e., the context name is given as a period. In an expression entered for immediate execution, any unqualified name, no matter what its use - reference, specification, call, definition -, is understood to be implicitly qualified by the current context. Thus unqualified names can be used for objects whose full names are qualified by the current context.

A function also has a context. If a fully qualified name was used for it in its definition, then the context is the one referred to in that name; otherwise, the function's context is the one that was current when it was defined (and indeed, its fully qualified name includes the name of that current context). All unqualified global names within a function are implicitly qualified by the function's context; the context in which the function is executed is irrelevant to their interpretation. When a function is suspended, the context for immediate execution is the function's context. If the context is changed while a function is suspended, resumption of execution will automatically change the context back. Completion of execution returns the context to what it was when the function was called.

   Local and Global Names

To avoid clutter in the workspace and to reduce the possibility of name conflict, a name can be local - i.e., have meaning only in the function in which it occurs and disappear when execution of that function is complete. Such a name must be unqualified, and it is made local by an Assignment within the function in which only the name appears to the left of the arrow. All qualified names are global. See "Scope of Names".

A function can see only global names and its own local names. A user can see only global names and the local names of the latest suspended function (and not pendent ones).

   Visible Use of a Name

A visible use of a name occurs when the name appears in A+ code directly, and not in a character string or a symbol. A use that is not visible is an implicit reference, which occurs through the employment of Execute () or Value (%). This distinction is important for dependencies, which are invalidated only by visible uses of names (cf. "Dependencies", especially "Evaluation" and "Dependencies Defined").

   Listing Names

System commands and system functions are provided for listing names of various kinds in the workspace:

   Reporting the Environment in the Active Workspace

A number of system functions and commands are available for inquiring about the active workspace:© Copyright 1995–2008 Morgan Stanley Dean Witter & Co. All rights reserved.