
<<CompilerMessagesDoc.tioga>>
<<Satterthwaite, January 7, 1986 10:14:34 am PST>>
<<>>
COMPILER ERROR MESSAGES
CEDAR 6.0  FOR INTERNAL XEROX USE ONLY
Compiler Error Messages
What the compiler is really trying to tell you
Ed Satterthwaite
  Copyright 1986 Xerox Corporation. All rights reserved.
Abstract: An attempt to provide some aid and comfort in interpreting the error messages produced by the compiler.
Created by: Ed Satterthwaite
Maintained by: Ed Satterthwaite <Satterthwaite.pa>
Keywords: Cedar, Compiler, Errors

XEROX            Xerox Corporation
                Palo Alto Research Center
                3333 Coyote Hill Road
                Palo Alto, California 94304

For Internal Xerox Use Only
1. Introduction
1.1. Using this Document
    This document lists all the error messages generated by the current (January 1986) version of the Cedar compiler.  In most cases, 
    it also provides an explanatory note that goes beyond the rather cryptic text appearing in the message itself or gives hints 
    about unobvious ways of provoking the error.
    The remainder of this section provides a little information about how the compiler is organized and the consequences for error 
    reporting and recovery.  Section 2 briefly discusses lexical and syntactic errors, and section 3, which is the meat of this 
    note, documents so-called semantic errors.  Section 4 can be treated as an Appendix.  It provides some background on the view 
    of types taken by the once proposed Cedar Kernel language.  Whether or not you like this view, the compiler is increasingly 
    using it internally, so some familiarity with it will help you understand some common kinds of type errors and how they are 
    reported.
    The strategies used in the Cedar compiler for reporting and recovering from errors will continue to evolve over time.  Major 
    changes will result in new versions of this document.  Your feedback can help too; let me know of your frustrations and wishes 
    in this area. 
1.2. Phase Structure and Error Recovery
    The Cedar compiler is organized as five phases (six counting a final phase that just writes the BCD file).  If you run the compiler 
    locally, you will probably notice some kind of feedback window in which a sequence of dots appears to indicate the progress of 
    the compilation.  One dot appears as each phase is started.  Lexical and syntactic errors are detected by the first phase.  
    Most semantic errors are found in the third phase, but some are detected by all the other phases as well.
    Errors are reported on a phase-by-phase basis; currently, there is no collation of messages issued by different phases.  Thus all 
    messages about syntax errors appear before, e.g., messages about type mismatches.  The compiler attempts to report errors as 
    early as possible and to maximize the amount of useful information per attempted compilation.  It does not always succeed.  
    Currently, the strategy is to continue through phase 3 unless phase 1 detects a syntactic error for which it cannot find an 
    acceptable recovery.  Thereafter, compilation terminates after any phase that detects an error.
    The compiler will not generate code for a program in which it finds errors.  In that situation, it will not create a new BCD file 
    and will make its best effort to delete any existing BCD files with the same name.
        Caution: If such a BCD file is locked, it won't be deleted.  Thus it's possible to have a valid BCD file corresponding to some 
        older version of the source even after an attempted compilation of the current version has failed.
1.3. Compiler Failures
    If you compile big programs, you will probably run out of storage from time to time.  The message reporting this has the following 
    form:
    Storage overflow in Pass <n>
There are a few tricks for getting a program that is near the borderline to compile without overflow; see a wizard if this seems 
vitally important to you.  Otherwise, the best strategy is to split the offending module.
    Either of the following messages indicates some sort of internal compiler error:
    FATAL COMPILER ERROR
    unimplemented construct
If you get one of these messages, please save the input and as much of the environment as possible and notify a compiler 
maintainer.  Both messages indicate that the compiler has encountered an unexpected situation.  In the case of a fatal error, the 
consistency of the compiler's code and global state is suspect; you should rollback before attempting further compilations. 
2. Lexical and Syntactic Errors
    These errors are detected by the first pass of the compiler and are reported as suggested by the following examples:
            i _ j + 1%;
                     ^ invalid character [163]
            i, j: NAT,
                     ^ syntax error [126]
        Text deleted is:  ,
        Text inserted is:  ;
In each case, the error log contains the text of the offending line, a pointer (^) to the offending position within the line, and 
the index in the source file of the character in that position.  Unfortunately, the ^ will seldom align correctly unless you are 
using a fixed-pitch font to view the error log; however, you can use the Position command in Tioga's Places submenu to scroll to 
and select the character corresponding to the index.
    Hint: Since editing will change the absolute indices of characters, it's easier to deal with multiple errors if you work through 
    the error log from back to front.
    A lexical error occurs when the compiler cannot convert the input stream to a sequence of valid tokens.  The following lexical 
    errors are currently recognized:
        invalid number            ill-formed or too large for 32 bits
        string unterminated or too long    maximum length is 2000 characters
        invalid character
        invalid atom            following "$"
        invalid escape sequence        following "\"
The compiler recovers by ignoring an invalid character or the internal structure of an invalid literal.
    A syntax error occurs when the compiler cannot accept the next token of the input stream as part of a syntactically correct 
    program.  The compiler attempts to recover by deleting and/or inserting tokens in the vicinity of the error until the 
    insertions and a reasonable number of additional tokens from the input stream are the prefix of a valid program.  The 
    insertions and deletions are reported as part of the error message.  The compiler does not attempt to evaluate the semantic 
    plausibility of such a prefix.  There are a few pecuiliarities of the Cedar language, such as the notation for discriminated 
    record types and for subrange types, that sometimes allow a highly implausible recovery and create a cascade of subsequent 
    errors.  In such cases, it's often most productive to fix the first error and recompile. 
    Caution: For historical reasons, the compiler ignores any text following a well-formed program.  This can cause strange behavior 
    when the sequence "END ." or its equivalent is misplaced.
3. Semantic Errors
    These errors are reported as suggested by the following example:
    k  is undeclared, at Test[170]:
        i _ j + k;
The error log displays the text of the line containing the start of the offending construct.  The number in brackets is an index in 
the source file.  In most cases, it's the index of the first token in the smallest declaration or statement containing the error.  
This is not terribly helpful when the error occurs inside a very long expression.
    As indicated in the list that follows, many messages begin with a reconstructed version of some Cedar expression (e.g, "k" in the 
    example above).  The reconstruction is done by unparsing an  intermediate representation.  The second and third passes of the 
    compiler try not to lose information and can usually report errors in terms of the original source code, perhaps with some 
    embellishment or canonicalization.  Later passes attempt a certain amount of compile-time evaluation and optimization that can 
    lose structure; it's unfortunately not too uncommon for the fourth pass to report an offending value in terms of its internal 
    representation, expressed as a decimal or octal number.
    The unparser does not fully expand deeply nested expressions; omitted subexpressions are indicated by "...".  There are also a few 
    constructs not currently handled by the unparser; the reconstructed text is either missing or is replaced by "..." in these 
    cases.
    Warning messages begin with the character string "warning: ".  The next two subsections list all the error and warning messages 
    respectively.  Within each subsection, the order is alphabetical according to the first non-bracketed, non-blank character of 
    the message.  The portions of the message that appear within brackets (<...>) are replaced by unparsed text as explained above 
    and vary from instance to instance of the message.

3.1. Errors
    attempt to access private fields
        In a constructor or extractor, even if the fields aren't mentioned and have defaults.
        Alternatively, discriminating a variant record with a private tag field or locking a MONITORED record with a private lock field.  
        Note that the lock field is declared implicitly and inherits the default visibility attribute of the record type.
    body or catch phrase nested too deeply
        Nesting depth exceeds 15, where the depth is 1 at the module level and increases by one for each (non-inline) procedure body or 
        catch phrase.
        Note: This error can be triggered by the expansion of an inline procedure containing local procedure declarations or catch phrases.
    <id> cannot be defaulted
        Omitted keyword in a keyword constructor, but the corresponding field has no default value.
    <id> cannot be defaulted or voided
        Omitted expression in a positional constructor or argument list, but the field in the corresponding position does not allow a 
        default.  The identifier is the field name and is omitted for anonymous fields or array components.
    <id> cannot be opened
        BCD file containing the included module cannot be opened, usually because it cannot be found in the current working directory.  
        Alternatively, the file was found but does not have the internal passwords used by the compiler for validity checks (file 
        incomplete, damaged, or produced by an older and incompatible version of the compiler).
        An included module can reference other modules not explicitly mentioned in the DIRECTORY of the program being compiled.  In some 
        circumstances, the compiler must access such an implicitly included module and will attempt to open it, possibly failing 
        with this message. The circumstances requiring such access are not easy to characterize precisely. Usually, the compiler 
        needs information about the internal structure of an enumeration or record type defined in the implicitly referenced module.
        This error frequently has the unfortunate side effect of producing a cascade of messages about undefined and misused identifiers.
    <id> cannot have a specified position
        Explicitly specified field positions are used in defining a record type that is not declared to be MACHINE DEPENDENT.
    compilation aborted
        User-requested abort.  Compilation terminates cleanly between phases.
    default return of anonymous value
        An explicit RETURN or RESUME that defaults the returned values to be the formal result variables, when those variables are unnamed 
        and have undefined values.  Alternatively, an implicit RETURN at the end of a procedure with such formal result variables.
        Note: The compiler suppresses this message for an implicit RETURN if it can discover that such a RETURN is unreachable.  Its flow 
        analysis is incomplete and conservative; sometimes this message appears because the compiler has not recognized that a case 
        analysis is exhaustive (put an ERROR on the ENDCASE to fix this), that a  loop cannot terminate normally, etc.
    <expr> does not allow an argument list
        But is followed by a bracketed list of expressions.
    <expr> does not allow indirect reference
        Does not designate a variable and cannot be used as the operand of @ or similar operator.  Alternatively, designates an unaligned 
        record field or a packed array element, for which the implementation does not support explicit address generation.
    <id> does not name a variant
        In the naming of a disciminated type, or as a case label in a discriminating SELECT.
    <expr> exceeds addressing limits
        If the expression is the identifier of a variable, that variable causes the size of a local frame to exceed 212-1 (4095) words.  If 
        the expression is a field name, that field causes the size of a record to exceed 212-1 (4095) words.  Note that variables 
        and fields are not necessarily allocated in lexical order.
        If the expression is a procedure identifier, allocation of compiler generated temporaries for that procedure causes the size of a 
        local frame to exceed 212-1 (4095) words.  If the expression is a STRING literal, allocation of space for that string 
        causes the overflow.
    <expr> explicit selection not permitted
        In a (non-copying) WITH ... SELECT discrimination, an explicit selector is supplied for a variant record that does not have a 
        COMPUTED tag.
    FATAL COMPILER ERROR
        Internal consistency failure.  See section 1.3.  Rollback before attempting further compilations.
    <id> found in wrong version
        When the compiler requires a specific version of a BCD file.
        For explicitly included modules, the compiler uses whatever version of the corresponding file is found in the working directory.  
        An included module can reference other modules not explicitly mentioned in the DIRECTORY of the program being compiled.  In 
        some circumstances, the compiler must access such an implicitly included module and must find the exact version referenced. 
         The circumstances requiring such access are not easy to characterize precisely. Usually, the compiler needs information 
        about the internal structure of an enumeration or record type defined in the implicitly referenced module.
        Currently, there is no good way of finding the chain of dependencies that leads to a particular implicit reference.  In puzzling 
        cases, you or, more likely, a wizard can use the SymbolLister in a rather awkward and painful way to get this information.  
        Listing the symbols of the explicitly included modules (possibly iterating until closure) generates a list of all possible 
        references and the reference paths.
    <expr> has a size exceeding implementation limits
        Assignment, comparison or allocation (using NEW) of an object with size exceeding 216-1 words.  Alternatively, indexing of an array 
        or sequence with components having a size exceeding 216-1 words.
    <id> has a type illegal for a tag
        Not an enumerated type for a variant tag, or not an index type for a sequence tag.
    <expr> has a type with no <operator> operation
        Operator missing from the cluster of the type.  See section 4.
    <expr> has an invalid default
        Specifying a TRASH (NULL) default for a type that would inherit a default initial value not including TRASH as an alternative.
        Alternatively, using the special form (bracketed expression) that allocates a STRING body as a default specification or as an 
        initial value in NEW.
        Alternatively, a formal result variable of an INLINE procedure that is unnamed but has a (non-TRASH) default initial value 
        (implementation shortcoming).
    <expr> has incorrect or ambiguous length
        Usually, a LOOPHOLE to a type with a size not equal to the size of its operand, or an operation such as comparison on sequences or 
        undiscriminated variant records in which different variants have different sizes.
        Alternatively, assorted size problems, including
        . an access to a variable or field with zero size (i.e., an empty subrange or array)
        . a conditional expression in which not all alternatives have the same sizes
        . incorrect size of a state vector (wizards only).
    <expr> has incorrect type
        Usually, a type that is not compatible with, and cannot be coerced to, some target type implied by the context.  See section 4.
        Note: The default safety attribute of a proc or signal type depends upon whether CEDAR appears in the header of the module defining 
        the type; type constructors that look identical can differ in the value of this attribute and can cause puzzling instances 
        of this message.
        Alternatively, a long (32 bit) value as a test selecting a case arm, when the value of the corresponding case selector is short 
        (Implementation shortcoming).
        Alternatively, a catchall for assorted type errors including the following:
        . a conditional expression in which the alternatives have incompatible types
        . no NARROW operation for a value requiring narrowing to the target type
        . a list constructor when the target type is not a list or REF ANY type
        . extraction from a value that does not have a record type
        . a catch label that does not have a signal or error type
        . a qualifier of NEW or FREE that is not a zone
        . a READONLY operand of FREE
        . incorrect pairing of base and relative pointers
        . OPEN of an object that does not have an interface or record type.
    <id> has invalid field width or alignment
        Violation of assorted restrictions in the definition of a MACHINE DEPENDENT record with explicitly specified field positions:
        . a record bigger than a word but not an integral number of words
        . a (non-variant) field bigger than a word but not an integral number of words or not word aligned
        . a tag field not at the beginning of a variant or sequence part
        . size of a variant part not equal to the size of the biggest variant
        . size of a sequence part not equal to that of the sequence with zero items
        . indexable part of a sequence not word aligned 
    <id> has no exportable value
        An exported procedure with an INLINE body, or an exported variable with "=" initialization to a constant.
    <expr> has no <operator> operation
        Its value (a type) does not have the indicated attribute or operator in its cluster.  See section 4.
    <expr> has no variants
        In a (non-copying) WITH ... SELECT discrimination, the selector does not designate a variant record.
    <expr> has nonconstant value
        In a context in which the language definition requires an expression with a value that can be computed statically by the compiler.  
        Note that a default specified as part of a type (not procedure) declaration in a DEFINITIONS module must be constant.
        Note: In an expression used as part of a subrange type definition or as the size of an opaque type, calls of INLINE procedures are 
        not allowed.  In other contexts, the expansions of such procedures are used in determining whether a value is constant, but 
        you should not count on the compiler's eliminating any but the simplest forms of INLINE bodies.
    <expr> has signed/unsigned ambiguity
        Operands in the expression are neither both signed nor both unsigned (according to the rather arcane rules used by Cedar).  
        Alternatively, a subrange or interval with such endpoints.
        This is an error for those operators in which the resulting bit pattern is dependent upon the representation assumed (e.g., /, <); 
        otherwise it is a warning.
    <id> has unknown or ill-defined size
        Declaration or allocation of a variable or field with a type having no well-defined size (e.g., a sequence or a size-unknown opaque 
        type).
        Alternatively, a recursive type definition or chain of definitions giving a type with indeterminate or impossible constraints on 
        its size (e.g., by mentioning T.SIZE within the definition of T).
    illegal index type
        Use of a long (32 bit) index type in defining an array or sequence type (implementation shortcoming).
    illegal initialization to body
        Binding or assigning a procedure body to an identifier that does not have a proc type or that has a proc type with ANY as domain or 
        range.
    illegal initialization to MACHINE CODE
        Binding a MACHINE CODE body to an identifier that does not have a proc type.
    illegal REJECT or RESUME
        Not within a catch phrase; alternatively, a RESUME in a catch phrase for ANY, for an ERROR, or for multiple SIGNALs with different 
        types.
    illegal RETURN
        In a catch phrase or PROGRAM body; alternatively, RETURN WITH ERROR in a catch phrase.
    illegal STOP
        Not in a main PROGRAM body, or in a PROGRAM body that returns a result.
    implicit system call
        Use of a language primitive that is implemented by out-of-line code.  This error is enabled only by the y compilation switch (for 
        wizards only, and probably not even for them anymore).
    improper use of an unsafe block
        An UNCHECKED block as the body of a procedure with a SAFE type, as the arm of a catch phrase for a signal with a SAFE type, or as a 
        statement in a CHECKED block.
        Use TRUSTED if you want to suppress the compiler's checking in these situations.   Note that the default safety attributes of proc 
        types and the default checking attributes of blocks both depend upon whether CEDAR appears in the module header.
    <id> improperly defined for a DEFINITIONS module
        Initialization of a procedure to a body that is not INLINE, or initialization of a variable with _ or with an expression that does 
        not have a constant value.
        Alternatively, a named import, or a procedure declaration nested within an INLINE body.
    incorrect discrimination
        Various intermixings of features from the old (non-copying) and new (copying) forms of WITH ... SELECT discrimination.
    index or interval type must be ordered
        In defining an array or subrange type, or specifying an interval.
    instruction has incorrect length
        More than eight bytes grouped as a single instruction in a MACHINE CODE body  (wizards only).
    interval bounds are out of range
        End points of nested subrange types don't nest; alternatively, the base type of subrange is REAL.
    invalid attribute combination
        Mutually incompatible attributes in a type constructor:
        . MONITORED + MACHINE DEPENDENT
        . SEQUENCE with * as a tag type
        . OVERLAID SEQUENCE
        . COMPUTED SEQUENCE, if components are reference-containing
    <id> is a misused INTERNAL
        Called from other than the body of an ENTRY or INTERNAL procedure, or forked within such a body.
    <id> is ambiguous without discrimination
        Use of a name that occurs in more than one arm of an OVERLAID variant record, when that use is outside a SELECT arm for a single 
        variant. 
    <expr> is an improper control variable
        Not a simple variable, or a simple variable declared in another module and imported.
    <expr> is an incorrectly used inline
        In an assignment or comparison requiring a proc value, as the alternative of a proc-valued conditional, in _ initialization, or in 
        a LOOPHOLE.
        Also, a fork of an INLINE procedure, or a call of one through a POINTER TO FRAME.
    <id> is an unmatched implicit import
        No principal instance of an implicitly imported interface when it is needed to bind objects (inlines or variables) imported 
        indirectly by another imported interface.  Either there are multiple explicitly imported instances of the needed interface, 
        or there are none but adding the name of that interface to the IMPORTS list would create a name conflict.  This situation 
        can arise only when importing an interface that itself imports other interfaces and uses inlines, variables, etc. from them.
        Alternatively, no principal instance of an interface when it is required by so-called object notation, because the number of 
        explicitly imported instances of that interface is not exactly one.
        Note: These errors arise from the interactions of some language misfeatures and some implementation shortcomings.  If you are 
        importing multiple instances of an interface and encounter problems, consult a wizard.
    <expr> is being assigned out of scope
        Into a variable that potentially outlives the nested procedure, signal or error (i.e., one declared within another procedure body). 
         Alternatively, forking a nested procedure, or supplying a nested procedure as an argument of a forked procedure.  These 
        are flagged as errors in CHECKED regions only.
    <expr> is discriminated unsafely
        Old (non-copying) form of WITH ... SELECT discrimination applied to a reference-containing record.  This is flagged as an error in 
        CHECKED regions only.
    <id> is exported with incorrect attributes
        As a length-specified opaque type, when the concrete type has a default initial value or has a nonstandard implementation of 
        assignment or equality (includes all REF and reference- containing types and most variant record types).
    <id> is exported with incorrect SAFE attribute
        For an exported value with a proc or signal type.  Always accompanied by another message about exporting the name with incorrect 
        type, even if the safety attribute is the only problem.
        Note: The default safety attribute of such a type depends upon whether CEDAR appears in the header of the module defining the type; 
        type constructors that look identical can differ in the value of this attribute.
    <id> is exported with incorrect type
        For an interface procedure, the type of the exported item is not compatible with the type of the interface item.  For an interface 
        variable, the type of the exported item is not equivalent to the type of the interface item.  For an interface type, the 
        type of the exported item is not TYPE.
        Alternatively, a variable with "=" initialization exported to an item that is not READONLY, or an exported type that is itself 
        opaque (implementation shortcoming).
    <id> is followed by a gap
        In the definition of a MACHINE DEPENDENT record type with explicitly specified field positions, the field does not extend to be 
        contiguous with the next field or, for the last field, to the required alignment boundary.
    <id> is INLINE and recursive
        Discovered in the process of expanding the inline.
    <id> is multiply defined
        In a single declaration sequence or USING list.
        Note that the formals, results, and outermost locals in a procedure body are considered a single declaration sequence for the 
        purpose of this check.  Also, the tag field in a variant record or sequence is considered part of the enclosing declaration 
        sequence.
    <id> is multiply defined
        As labels in an EXITS or REPEAT clause.
        Note that such names form a space entirely disjoint from the name space of normal declarations.  See the manual for the details of 
        the exact scope rules for these names.
    <id> is not a legal variant tag
        In the label of a variant case in a record type definition.
    <id> is not a module name
        The interface name specified in a DIRECTORY entry does not match the module identifier in the corresponding included file.
        Note that the interface name to be matched is the one following "TYPE" in the DIRECTORY entry if that name is present; otherwise, 
        the one preceding the colon.
    <id> is not a type
        Where the context demands a type.
    <expr> is not a variable
        Does not designate a variable and cannot be used as the destination of an assignment, as the operand of WAIT, NOTIFY or BROADCAST, 
        or as a monitor lock.
    <expr> is not address (@) of a variable
        The FREE operation for a counted zone requires an address of a REF variable, explicitly generated using @, as its operand.
    <expr> is not importable/exportable
        A module importing or exporting itself, or a DEFINITIONS module importing a PROGRAM module.
    <id> is not valid as a field selector
        Following a dot.
        This message often means that the identifier has been omitted from the corresponding USING list.  Confusingly, the qualified 
        procedure names in so-called object notation must appear in corresponding USING lists (if present), despite the fact that 
        identifiers of record fields and the like must not. 
        Note: When referencing an included module, the compiler cannot always distinguish between names that are undeclared and those that 
        are private.  Also, a failure to open the BCD file containing an included module can give an unfortunate cascade of these 
        messages.
    <id> is not valid as a key
        In a keyword constructor.
    <id> is out of order
        In the definition of a MACHINE DEPENDENT enumeration, the lexical order and the order implied by the representation specification 
        are different.
    <expr> is out of range
        Compile-time bounds fault.
    <id> is private
        In the scope of an OPEN or in a field designator, constructor, extractor, etc.  Alternatively, in the USING list for an included 
        module.
    <id> is repeated as a key
        In a keyword constructor.
    <id> is undeclared
        In the current scope, or in the included module (for a USING clause), or in an enumeration (for $id as a literal).  See the manual 
        for details of the rather confusing scope rules applicable to ENABLE clauses, EXITS, etc.
        This message often is a symptom of a mistake in a USING list or OPEN clause. 
        Note: When referencing an included module, the compiler cannot always distinguish between names that are undeclared and those that 
        are private.  Also, a failure to open the BCD file containing an included module can give an unfortunate cascade of these 
        messages.
    <id> is undeclared
        As the destination of a GOTO.
        Note that such labels constitute a naming space entirely disjoint from the name space of normal declarations.  See the manual for 
        the details of the exact scope rules for these labels
    keywords not permitted
        In various forms that look like procedure calls or record constructors but aren't (indexing, etc.).
    <id> labels multiple variants
        In the labels of multiple variant cases in a record type definition
    <expr> lacks a tag needed for discrimination
        Missing selector expression in discriminating a variant record with COMPUTED tag.  Alternatively, narrowing such a record.
    <id> leads to a circular type definition
        Recursive type definition or chain of definitions gives a type with infinite size.
    MACHINE CODE cannot be CHECKED
        Use TRUSTED.
    misplaced catch phrase
        In various forms that look like procedure calls but aren't (indexing, constructors, etc.); alternatively, attached to RETURN WITH 
        ERROR.
    misplaced EXIT or LOOP
        Not within DO ... ENDLOOP brackets (which must be within the same procedure body).
    misplaced opaque type declaration
        Not at the top level of a DEFINITIONS module.
    misplaced RETRY or CONTINUE
        In a declaration or an OPEN clause (where these forms are illegal).
    misused DESCRIPTOR
        In defining a type.
    misused LONG
        In defining a type.
    misused RELATIVE
        Base type is not a pointer type, or offset type is neither a pointer nor a descriptor type.
    misused VAR
        For other than the declaration of an exported variable in a DEFINITIONS module (where either VAR or READONLY is recommended).
    mixed explicit and implicit field positions
        In defining a record type.
        Note: The positions of the variant part and its tag must be specified in a MACHINE DEPENDENT variant record if positions are 
        specified for fields in the common part.
    <expr> must be in MDS
        Has an address involving a long pointer or ref (currently such an address is disallowed only for a PORT used in a coroutine 
        transfer).
    <id> must come from an imported interface
        Procedure (including an INLINE) or variable is defined in an included module but is not taken from an imported instance of that 
        module.  Note that this can happen either because the module is not imported at all or because the interface type and 
        instance are given different names by the IMPORTS clause and the former is used.
    <expr> must have an interface type
        In IMPORTS, EXPORTS or SHARES.
    <expr> overflows
        Compile-time overflow, using the same rules that would be used at runtime if there were complete runtime checking (which there 
        isn't).
        Note the interaction with the somewhat unfortunate language rules for lengthening operands.  256*256 overflows, even in a context 
        that eventually requires a long number; 256.LONG*256 does not.
    <id> overlaps another field
        In the definition of a MACHINE DEPENDENT record type with explicitly specified field positions.
    procedure used as a statement returns a value
        Also for SIGNAL, JOIN, etc.  Prefix "[ ] _" to discard the value.
    <id> required for lock
        ENTRY or INTERNAL procedure does not have a formal parameter matching in name and type that of the formal specified in the LOCKS 
        ... USING clause.
    <id> requires a base value
        Unqualified reference to a field of a record in the specification of a default initial value for a field or type defined within the 
        same record type. 
    <id> requires an initial value
        Declaration or allocation of a variable with a type that requires an explicit initial value.
    <expr> requires explicit type
        Because context does not supply enough target information for disambiguation (constructors, NARROW, VAL, etc.).
        Anomaly: The constructor of a discriminated variant record requires pieces of the type identifier to appear in two different 
        places.  The undiscriminated type is written before the opening bracket of the entire constructor and can be omitted when 
        implied by context.  The identifier of the particular variant is written before the bracket opening the variant part and 
        can never be omitted, even when it is implied by context.
        Another anomaly:  For VAL and ALL, you can't supply the type explicitly but must introduce and initialize a variable or use some 
        similar artifice.
    <expr> specifies an inadmissable test
        In a WITH ... SELECT discrimination, the label of a case arm is not a literal or does not test for simple equality.
    state vector has improper offset
        State vector is not a local variable or was assigned too large an offset for the instructions that save and restore processor state 
        (wizards only).
    string literals not permitted in DEFINITIONS
        Implementation shortcoming.
    <number> too few elements in list
        Usually in a positional argument list or constructor; alternatively, in the operand lists of assorted builtin operations that use 
        funtion-like notation.
        Note:  The compiler will have used any available defaults to lengthen the list before issuing this message. 
    <number> too many elements in list
        Usually in a positional argument list or constructor; alternatively, in the operand lists of assorted builtin operations that use 
        funtion-like notation.
    <number> too many exported variables
        More than 64 variables exported from a single PROGRAM module.
    <number> too many interface items
        A total of more than 2048 (non-INLINE) procedures, signal, errors, variables and opaque types declared in a single DEFINITIONS 
        module.
    <number> too many procedure or signal definitions
        More than 127 (non-INLINE) procedures or more than 128 signal and error CODEs declared in a single PROGRAM module.
    type must be MACHINE DEPENDENT
        Representation specifications are used in defining an enumerated type.
    unimplemented construct
        Internal consistency failure that leaves the compiler in a clean state.  See section 1.3.  Occasionally a side effect of previous 
        errors.
        Alternatively, attempted use of some partially implemented new features related to PAINTED and VAR types.
    unmonitored ENTRY or INTERNAL
        Not in a MONITOR.
    unmonitored WAIT or NOTIFY
        Not in the body of an ENTRY or INTERNAL procedure.
    unrecognizable type constructor
        Application of FRAME to a non-proc, non-program value, or compiler confusion (perhaps because of other errors).
    <expr> uses an unsafe operation
        Usually, calling an UNSAFE procedure or raising an UNSAFE signal.  Alternatively, assorted constructs invoking unsafe builtin 
        operations, including
        . port call or JOIN
        . indexing an array descriptor
        . dereferencing a relative pointer
        . loading or storing processor state (wizards only)
        These are flagged as errors in CHECKED regions only.  Note that the default safety attribute of a proc or signal type depends upon 
        whether CEDAR appears in the header of the module defining the type. 
    <expr> uses an unsafe <operator> operation
        Note that field selection, indexing or procedure application can force automatic dereferencing of the left operand.  If such 
        dereferencing is unsafe, the operator reported is the implicit ^.  These errors are flagged in CHECKED regions only.
    variable or field too large
        A type with size greater than 228-1 words or 212-1 words (maximum depends on context).
3.2. Warnings
    <id> appears uninitialized
        Value of the variable appears to be used before the variable is initialized.  This warning is enabled only by the u compilation 
        switch. 
        Note: The compiler does a very simplistic data- and control-flow analysis to generate these warnings.  The absence of a warning is 
        no guarantee of proper initialization, nor is the presence of this warning proof that there is a genuine initialization 
        error.
    <id> cannot be opened
        For module replacement, the BCD file containing the old version of the module.  Otherwise, this is an error.
    discrimination on opaque types is unimplemented
        Implementation shortcoming.  If T is an opaque type and x is a REF to an object with the corresponding concrete type, then 
        ISTYPE[x, REF T] will usually be FALSE; also, NARROW and discriminating selection will usually fail.
        Unless you are a wizard, treat this warning as an error.
    <id> has been padded
        In the definition of a MACHINE DEPENDENT record type without explicitly specified field positions, the number of bits allocated to 
        a field because of alignment or boundary constraints exceeds the number required for the minimal representation.
    <id> has global strings preventing replacement
        Either STRING literals or STRING bodies in the global frame (for users of the System Modeller only).
    <id> has incompatible attributes for replacement
        A global procedure does not have a compatible type and the same entry point index in old and new versions of a compiled module, or 
        a global variable does not have the same type and offset in both versions (for users of the System Modeller only).
        Note:  If the attributes of a large number of objects change, this warning appears only for the first few that the compiler 
        notices.  Unless you use the ~s compilation switch, small changes in the pattern of referencing global objects can cause 
        large changes in their addresses (because of sorting done by the compiler).
    <expr> has signed/unsigned ambiguity
        Operands in the expression are neither both signed nor both unsigned (according to the rather arcane rules used by Cedar).  This is 
        a warning for those operators in which the resulting bit pattern is independent of the representation assumed (e.g., +, =); 
        otherwise it is an error.
    <expr> has zero length
        Forming a descriptor of an empty array.
    instruction has incorrect length
        An instruction in a MACHINE CODE body does not have the number of operand bytes expected by the compiler (wizards only).
    <id> is never referenced
        A local variable, a global variable that is not PUBLIC, or a label that is declared but not otherwise referenced.
        Alternatively, an entry in the DIRECTORY clause that supplies no items to the including module, or a name mentioned in a USING list 
        that is never referenced.
    <id> is private but matches an export
        Has a name and type matching an item in one of the interfaces exported by a PROGRAM module but is not PUBLIC.
        Caution:  There is no corresponding check that every PUBLIC identifier in a PROGRAM module is exported to some interface.
    <id> matches a constant in an exported interface
        Is public and has a name matching an item in one of the interfaces exported by a PROGRAM module, but that interface item is a 
        constant and will not be affected by the export.
    multiple initialization with a pointer
        In a declaration of multiple pointer, REF or descriptor variables, the same non-constant value is assigned to  more than one 
        variable.
        Note: This warning is dubious and probably obsolescent.  It was originally provided to draw attention to the sharing of any space 
        allocated for the bodies of STRING variables by such declarations. 
    <id> receives no exported values
        For an exported interface.
    <id> referenced in different versions
        References to two included modules with the same module identifier, say Z, but different version stamps.  Frequently, one or both 
        references arise indirectly; e.g., the module being compiled doesn't mention Z but includes X and Y, both of which depend 
        upon Z.
        This is not necessarily an error; the compiler has no way of knowing whether one of the versions is obsolete or just intentionally 
        different.  In the former case, a type error can occur if the checker attempts to match a type from X.Z with the 
        corresponding type from Y.Z.  This warning is issued to alert you to the possiblity of such otherwise baffling error 
        messages.
        Currently, there is no good way of finding the chain of dependencies that leads to a particular implicit reference.  In puzzling 
        cases, you or, more likely, a wizard can use the SymbolLister in a rather awkward and painful way to get this information.  
        Listing the symbols of the explicitly included modules (possibly iterating until closure) generates a list of all possible 
        references and the reference paths.
    <id> supplies no imported values
        For an imported interface.
    unreachable code
        Obvious cases in which all syntactic predecessors are RETURNs, ERRORs or GOTOs.  Also, an alternative in a WITH ... SELECT 
        following one in which the discrimination always succeeds.
    <expr> will use unsigned comparison
        An unsigned comparison with a suspicious and perhaps unintended constant operand (e.g., x < 0).

4. The Compiler's View of Types
    Many of the semantic errors encountered in practice are consequences of the type checking done by the compiler.  The Cedar Kernel 
    takes the view that a type is a pair consisting of
    a predicate, which is a function from values to BOOL
    a cluster, which is a collection of name-value pairs, where the values are normally the attributes and operations associated with 
    the type.
Every expression e has a syntactic type denoted by of a literal, by the syntactic form of that literal.  Other expressions are viewed as the results of applying procs, either 
primitive or user-defined.  The syntactic type of the result is determined by the range type of the proc in the outermost 
application, and most type checking consists of assuring that each argument has a type compatible with the corresponding formal 
domain type.
    Cedar clusters allow the use of "object notation" to provide convenient and concise overloading of operator names.  There are two 
    cases:
    If 
    Otherwise, e.n[args] usually is shorthand for (    the operand to the left of the dot; that is expected to yield an operator which in turn is applied to the value of that operand 
    plus the other arguments, if any.
In the second case, 
    In the terminology of the old Mesa manual, an argument freely conforms to     freely conforms or a suitable coercion can be found.
    In this scheme, type checking can fail in two ways: the operator cannot be found in the cluster of the leftmost operand, or some 
    operand (including the leftmost) has a type incompatible with the corresponding formal.  These two situations correspond to two 
    general classes of error messages, respectively
    e has a type with no n operation
    arg has incorrect type
In the first case, the compiler does not know the type required and can only report that the value supplied is not suitable.  In 
the second case, the compiler has a clear idea of the required type; subsequent versions of the compiler will try to report it in a 
concise and readable way.  Note some consequences:
    This desugaring gives an asymmetric interpretation to the arguments of operators, such as = or +, that are normally considered 
    symmetric.  Thus essentially similar errors can be reported differently, depending upon the position of the operand.  Life is 
    hard.
    Type errors in the first operand are most critical.  If the compiler finds an operation in the wrong cluster, it is very likely to 
    report type errors for each of the other operands.  There is no attempt to consider all the operands and choose an operator 
    that minimizes the total number of errors.
    Current Cedar only partially supports the definition and use of clusters for user defined types.  On the other hand, every built-in 
    type comes with a predefined cluster, and every built-in type constructor produces a type with a cluster that can be defined in 
    terms of the constructor and its arguments.  For some of the resulting operations, there is a "sugaring" rule that allows a 
    more conventional or more concise notation to be used for their application.  These forms are defined in terms of the 
    corresponding desugarings, which map back into dot notation.
    Examples:
        sugared        desugared        interpreted
        
        -x          x.UMINUS                x+y          x.PLUS[y]                MAX[x, y, z]      x.MAX[y, z]                WAIT c        (@c).WAIT        CONDITION.WAIT[@c]
