YAL provides a facility whereby type declaration statements, ALIAS statements, RESERVE statements, and similar objects can be organized into packages that can then be invoked in other programs by a single statement. If, for example, complex numbers were not defined in YAL, a large number of ALIAS statements would be required to set up all the built-in functions and operators to call new routines which would perform the required operations.
To make it more practical to set up and use new types, or subroutines with specialized calling sequences, YAL posesses the ENVIRONMENT statement, and its counterpart the USE statement, defined below.
(ENV, ENVIR, ENVIRON)
The ENVIRONMENT statement has the syntax
ENVIRONMENT environment-name
and acts as the header for an environment just as a SUBROUTINE statement acts as the header for a subroutine.
Following this statement is any number of ALIAS, STATEMENT, RESERVE, XSUB, XFUN, DEFINE, or PSUB, PFUN, et cetera, statements, as well as other type declaration statements (especially CONSTANT, ORDINAL, and STORE) terminated with an END statement. Executable statements are allowed within PFUNs, PSUBs, and so on, but not otherwise.
These statements are, in effect, included in the text of calling programs, up to, but not including, the END statement, except that any variable names used within them are strictly local to those statements, and do not conflict with use of the same name elsewhere. STORE and DUMMY statements and type declaration statements involving dummy variables are allowed, and type names are not local, but are made available to the program in which the ENVIRONMENT is USEd. Any SUBROUTINE or FUNCTION or other externally-compiled subroutines following the environment block will have their object code placed in an 'environment' rather than a normal object module, until an extra END statement is encountered. Unlike variables, the subprograms, both external and internal, in the ENVIRONMENT are also made available, as are their ALIASes.
Also, types declared within the program 'calling' the environment, as well as ALIASes, RESERVEd words, and so on, are not effective within the environment text. Such items within the environment do affect the program using it, as this is one of the main purposes of environments.
The default that variables are local, but everything else (types and subroutines) is available, can be overriden with the PRIVATE and PUBLIC statements (PRIVATE name,name,... and PUBLIC name,name,...). This may be useful, for example, in making only a subroutine's alias, but not its original name with a less useful calling sequence, available. This is useful if non-dummy variables are to be created within an environment header as well. Also, LIST and NOLIST directives are allowed within an environment header; listing is restored to availability after an environment header terminates without the need for a final LIST directive.
Note that a PRIVATE object is still accessible to ALIAS statements within the environment block, which may cause use of the PRIVATE object in the program; only direct use by name of a private object is inhibited.
Also note that some systems may not allow the placing of externally-compiled subroutines in ENVIRONMENTs; in this case, the use of these subroutines has to be separately requested at load time.