Errors defined in gardens point oberon 
  1 Line ends inside literal string
Literal strings are limited to a single line. Commonly, this error is due
to omission of the closing quote (which must match the opening quote --
either ' or "). If you wish to construct literal strings longer than editor
or system line length limits, you must do so by programmed concatenation.
\
  2 Illegal character in input file
All characters within the Oberon character set are acceptable, and control 
characters in the range 1X to 1FX are ignored. Other characters are invalid. 
If there is no apparent invalid character, use your text editor's "show 
non-printable characters" option or some dump utility to check for spurious 
characters.
\
  3 Input file ends inside a comment
This error will occur if a closing comment bracket is omitted. Note that
comments nest in Oberon, so that a subsequent closing bracket will match
only its corresponding opening bracket; note also that an intervening 
space between the '*' and the ')' characters will destroy a comment bracket.
Since end-of-file is indicated by a null character (0X), this error will 
also occur if a null is introduced within a comment.  The error is reported 
at the beginning of the unclosed comment.
\
  4 Invalid exponent in REAL constant
Immediately after the 'E' or 'D' which introduces a real exponent, there must
follow an optional sign, and then an unsigned integer.
\
  5 Illegal character in numeric constant
Numeric constants may contain only --
	digits 0..9 for decimal (no suffix), 
	or 0..9,A..F for hexadecimal (H or X suffix).
\
  6 Floating-point error during constant evaluation
The error value "HUGE" was produced when this constant was evaluated. 
See the machine reference manual for floating-point limits.
\
  7 Number too long
Numeric constants are assembled in a buffer which is currently more than
large enough for the number of significant digits in a double-precision 
floating point value.
\
  8 Constant too large 
Character constants are limited to 0FFX and integer constants
to MAX(INTEGER). 
\
  9 Illegal use of underscore in identifier
Underscores are not allowed in identifiers in Oberon. These rules are relaxed 
in foreign or interface modules, or in any modules which import such modules. 
In that case, the use of underscores is entirely free, and error 9 should 
not arise.
\
100 Invalid symbols precede start of module
\
101 No identifier at end of module
\
102 No fullstop at end of module
\
103 Expected END symbol
\
104 Expected module END symbol
\
105 Expected semicolon
\
106 Expected declarations
\
107 Expected equals sign
\
108 Expected identifier
\
109 Expected comma
\
110 Expected ')' symbol
\
111 Expected qualified identifier
\
112 Expected ']' symbol
\
113 Expected OF symbol
\
114 Expected colon
\
115 Expected '}' symbol
\
116 Expected '|' symbol
\
117 Expected addops
\
118 Expected mulops
\
119 Expected DO symbol
\
120 Expected UNTIL symbol
\
121 Expected ':=' symbol
\
122 Expected TO symbol
\
123 Expected THEN symbol
\
124 Expected start of type
\
125 Expected start of factor
\
126 Expected BEGIN
\
127 Expected IS IN symbols
\
128 Expected literal string
\
129 Premature exit: too few ENDs in  block
\
130 Expected END identifier;
\
131 Resynchronizing here
gpo uses the names at the end of procedures and modules to help in recovery 
from errors which are due to too many or too few ENDs.  In the case that the 
'END identifier' is found too soon, gpo abandons parsing the rest of (possibly 
nested) statement sequences and issues error 129. 

If an END is found but the expected identifier is missing then error 130 is 
emitted and gpo searches for an END with the matching identifier. This search 
will stop at the start of any new declaration, so that a simple omission of 
the identifier will not cause any information to be skipped. However, if there 
are too many ENDs gpo will find the matching one, and issue "error" 131 to 
announce that it has found the correct resynchronization point.
\
132 Expected start of StatementSequence
\
133 Expected start of Statement
\
200 Identifier at block end does not match
Oberon requires that the END of a module or procedure be followed by the name 
of the module or procedure.  Either you have omitted the matching identifier, 
or mis-spelt it, or perhaps incorrect pairing of ENDs with structures has 
misled the compiler? 
(Errors 129 -- 131 should catch most incorrect pairings) 
\
201 Symbol file missing
You have tried to import from a module, and its symbol file was not found.   
	Is the module name spelt correctly? 
	Has the module been compiled? 
	Is it in the current path? 
	Do you have read access to it?
\
202 Identifier is not exported from module
You have tried to use a particular identifier from an IMPORTed module;  
the module's symbol file was found, but that identifier was not exported.
Is it spelt correctly (or at least the same way -- Oberon is case sensitive). 
Is it defined in that module?
(Quick check: "grepdef identifier" will find the identifier no matter which 
   file it is in, or what directory on the search path the file may be in).
\
203 Identifer already known in this scope
You are trying to define a new object, and the name used already has some
other meaning in the current scope.  It may been an IMPORTed module's name, 
or declared previously in this scope.  If you wish to use a similar name, 
Oberon's case-sensitivity may be used to distinguish them; but beware of 
confusion later -- two variables of the same type, distinguished only by 
case, could easily be confused; on the other hand, two variables of different 
type, or a type and a variable, would almost certainly cause a compiler error 
if accidentally transposed.
\
204 Identifier not known in this scope
You are using an identifier which has no definition visible in this scope. 
Did you mis-spell it?  If it is IMPORTed then the identifier must be
qualified by the module name. 
\
205 Qualified identifier is not a type name
In a situation where the syntax requires the name of a type, the identifier
you have used is known, but is not a type name.  Could it be a mis-spelt name 
matching another identifier? Or did you forget that a type is required here?
\
206 Expression is not compatible with declared type
Oberon enforces strict agreement between types of expressions and the context 
in which they are used. This error occurs if a label of a CASE statement 
branch does not match the selector type.
\
>The expected type is <
while the actual type is >
\
207 Expression is not a constant
The syntax requires a constant here. eg. case selectors. 
\
208 Parameter is of wrong type
This actual parameter does not match the type required by the formal
parameter in the procedure declaration. This includes built-in functions
such as ABS, CAP & CHR.
-- or --
This argument to a built-in procedure or function is not a variable or type
designator.
\
209 Range of type exceeded
A value which can be checked at compile-time has been found to be out of 
range. These include constant arguments to built-in procedures and functions,
the results of evaluating constant expressions and set elements.  
\
210 Too many parameters
You have supplied too many parameters for the procedure called.  Check the 
definition: in the documentation for built-in procedures, in the imported  
module for external procedures, or in this module for local procedures.
\
211 Type incompatible operands
In general, operators combine operands of the same types; exceptions such
as the set membership operator IN still require compatibility between the
element being tested for membership and the base type of the set.

Note that if this error occurs, no check is made for the appropriateness of
the operator; on correcting the operand incompatibility, an inappropriate
operator will give an error such as 231 -- 232.
\
>The left hand expression type was < 
the right hand expression type was >
\
212 Not of Boolean type
The conditions which are used in IF, WHILE and REPEAT statements must be  
Boolean.
\
213 Record field name is not unique
Within a single record, each field must have a distinct name; this includes
type bound procedure names. Fields of other records (including records which 
are the types of fields of this record) may of course re-use the same names, 
since qualification by their variable or field name prevents an ambiguity.
\
214 Case expression/selectors of wrong type 
Oberon only allows case statements where the expression and the labels are
either integer types or CHAR.   
\
215 Attempted field selection not on a record structure
In the syntax a.b, a has been determined not to be a module name;  however,
it is also not a variable of record type, so that the apparent selection of
field (or type bound procedure) b is invalid.
\
216 Fieldname not known for this type
In the syntax a.b, a is a record variable name, but b is not a field or
a type bound procedure of that record type.
\
217 Designator is not a variable
There are various places where an object must be a variable: on the left-hand 
of an assignment; as the control variable of a FOR loop; anywhere where 
subscripting, field selection or dereferencing is performed; anywhere
where type testing (including WITH statements) is performed.
\
218 Attempted pointer dereference not on a pointer type
Clearly, only pointers can be dereferenced ^ -- that is, variables whose
type is POINTER TO something or SYSTEM.PTR.
\
219 Attempted array index not on an array type
Only arrays can be subscripted ([]).
\
220 Designator is not a function
An object which appears to be a function call is known to be some other
type (including a proper procedure).
\
221 Too few parameters
A procedure or function call does not have as many parameters as required
by the procedure or function declaration.
\
222 Designator is not a procedure name 
An object which appears to be a procedure call e.g. P(...); is not. 
It may be a function, or some other type.
\
223 Actual value parameter is not assignment compatible with formal
Since a formal value parameter is treated as a local variable to which the
value of the actual parameter is assigned at procedure entry, the same
compatibility rules as for assignment statements apply.

Assignment compatibility is defined as follows --
 * identical types are compatible;
 * numeric types where the formal type includes the actual type;
 * record types where the actual type is an extension of the formal type;
 * pointer types where the actual type is an extension of the formal type;
 * strings are compatible with string variables of equal or greater length;
 * open arrays are compatible with any array where the element types are the same; 
 * procedure types are compatible with any procedure with matching formals.
\
>The formal parameter type was >
the actual parameter type was <
\
224 Actual variable parameter not identical to formal
Since a formal variable parameter allows direct access to the corresponding
actual parameter, the compatibility requirements are strict -- actual and
formal must be of identical type or if the formal parameter is a record type
then the actual parameter must be an extension of that record type. Note that 
identical means the same named type -- it is name equivalence which is required,
not just structural equivalence.
\
>The formal VAR param type was >
the actual variable type was <
\
225 Actual variable parameter must be a variable
Since an actual variable parameter may be altered by a procedure, it must
be a variable. Constants could not be altered, and expressions have no
memory location to hold the updated value.

Also returned if the argument of SYSTEM.ADR is not a variable.
\
226 Incompatible open array element type
Formal parameters of open array type are compatible with actual parameters
where
  * they are the same type
  * the actual is any array and the element types of the formal and the
      actual are array compatible
\
>The formal open array param element type was >
the actual array element type was <
\
227 Expression not assignment compatible with variable
Assignment compatibility is required in an actual assignment statement, and
also between the initial value of a FOR loop and the control variable.

Assignment compatibility is defined as follows --
 * identical types are compatible;
 * numeric types where the formal type includes the actual type;
 * record types where the actual type is an extension of the formal type;
 * pointer types where the actual type is an extension of the formal type;
 * strings are compatible with string variables of equal or greater length;
 * open arrays are compatible with any array where the element types are the same; 
 * procedure types are compatible with any procedure with matching formals.
\
>The type of the variable was > 
the type of the expression was <
\
228 Return value not assignment compatible with function type
The value RETURNed by a function procedure must be assignment compatible
(see error 227) with the declared result type of the function.
\
>The declared return type was <
The return expression type was >
\
229 Expression is not of type CHAR
The operand of standard functions CAP and ORD must be CHAR.
\
230 Duplicate case selector in this range
Each case branch selector must occur only once, so that the statements to
be performed are uniquely determined. Have you included this value in a
range, as well as this occurrence?
\
231 Operand(s) not of Boolean type
The single operand of NOT, or either operand of AND or OR, must be Boolean.
\
232 Operand(s) not of numeric type
Arithmetic operators apply only to numeric operands.
\
233 Operand(s) not of whole number type
The operators DIV and MOD apply only to operands of integer types,
implementing whole number arithmetic. 
\
234 Not a constant of integer type
The syntax requires an integer constant as the BY expression for a FOR loop,
as the length(s) in an array declaration 
-- or --
The second parameter to LEN and ASSERT or the parameter to HALT.
\
235 Cannot have static array of open array
Open arrays can only be the base types for pointers or procedure
parameters.  An array of open array is illegal but an array of
pointer to open array is legal.
\
236 Function return type cannot be record or array
Oberon allows functions to return values of any type other than record or
array.
\
237 Pointer base type must be record or array
All pointers in Oberon must point to either a record or an array. 
\
238 Only static variables can be exported
Variables declared local to procedures cannot be exported from a module.
Only variables declared global to the module can be exported.
\
239 Cannot export nested procedure
Only procedures declared in the global scope of a module may be exported.
\
240 Receiver of type bound procedure is wrong type
Procedures may only be bound to either a record type or a pointer to 
record type.
\
241 Cannot export field of non-exported record
Fields or a record or procedures bound to a record type may only be exported
if the record type itself is exported.
\
242 Type cannot be read only export
Only variables can be read-only, not types.
\
243 Procedure cannot be read only export
Procedures can only be exported (*) or not exported.  Only variables can be
read-only, not procedures.
\
244 Invalid elaboration of forward procedure
The forward (^) definition of this procedure and its current definition do
not have matching formal parameter lists. 
\
245 Invalid redefinition of type bound procedure
The type bound procedure which this procedure redefines and this current 
procedure definition do not have matching formal parameter lists. 
\
246 Open array can only be pointer target type or formal parameter
Open arrays can only appear as the target type of a pointer eg.
	TYPE
	  OpenArray = POINTER TO ARRAY OF CHAR;
or in a parameter list as in
	PROCEDURE Proc (VAR str : ARRAY OF CHAR);
\
247 Not of integer type 
The parameters to certain standard procedures such as DEC, INC, INCL, EXCL 
and NEW must be of integer type.  This is also true for the control variable
and the upper limit for FOR loops, and array indexes. 
\
248 Type is not a basic type
The parameter to the standard functions MIN and MAX must be a basic type.
\
249 Too many dimensions for open array
The number of length parameters to the standard procedure NEW for open arrays
is larger than the number of dimensions of the array variable specified in
the first parameter.
\
250 Not of set type
The first parameter to the standard procedure INCL and EXCL must be of type SET.
\
251 Not of pointer type
The first parameter to the standard procedure NEW must be a pointer.
\
252 Expression must be non zero integer
The constant BY value in a FOR loop, and the size constant of an array must be 
greater than zero. 
\
253 Test type is not static extension of variable type
The type to be tested against in a WITH statement or IS expression must
be an extension of the type of the variable.
\
254 Set elements may only be integers
The set in Oberon is the set of integers from MIN(SET) to MAX(SET).
\
255 Target of forward reference not declared
Oberon generally expects that identifiers be declared before use, but
there are exceptions: the target type of a pointer (Fred in POINTER TO Fred),
the formal parameter and result types of a procedure type, and procedure
names. These names must be subsequently declared within that compilation
unit. Because of different internal processing of types and procedure names,
gpo reports the two cases differently. Error 255 reports incomplete type
definitions, at the point where it becomes clear that no definition can
appear.  Error 204 occurs for missing procedures. 
\
256 Not pointer to open array type
For a call to NEW with more than one parameter, the first parameter must be
a pointer to an open array.
\
257 Case expression is a constant
The expression to be tested by this case statement is a constant value.
\
258 Expression cannot be aligned with specified type
When an expression is cast to another type, using SYSTEM.VAL, the alignment 
requirements of the new type must not be any greater than the old. 
Since SYSTEM.VAL does not generate any code, the old bit pattern, in its 
old alignment, must be usable as a value of the new type. Thus, for example,
an ARRAY 4 OF CHAR cannot be cast to INTEGER, since the required word 
alignment cannot be guaranteed. 
\
259 RETURN not within a procedure 
A RETURN statement cannot appear in the body of a module.
\
260 Missing RETURN statement for function
This function does not contain a RETURN statement and therefore the program
will fail. 
\
261 Illegal access of redefined procedure 
You can only access a redefined procedure within the body of the redefining
procedure and via the receiver variable eg. a.b^ is only legal if within the
body of procedure b and a is the receiver of procedure b.
\
262 Read Only variable threatened 
Values imported as read only may not be used on the left hand side of an assignment
statement, sent as a VAR parameter to a procedure, or have their 
address taken.
\
263 Array index out of bounds 
An array index value that can be calculated at compile time has been found
out of the range of valid index values for the array type indexed into. 
\
264 Redefined procedure does not exist
You have tried to call a redefined procedure from within the body of the 
redefining procedure (via the ^ call) and the redefined procedure does
not exist.  Check your order of declaration - have you declared the 
redefinition before the original procedure?
\
265 Procedure declared forward was not elaborated
A procedure declared using the uparrow (^) was not elaborated within the 
same block. It is a rule that the forward declaration and its elaboration 
must be in the same lexical scope.
\
266 Variable is of wrong type
The variable in the IS expression or WITH statement must be a pointer to
a record type or a variable parameter of record type.
\
267 Qualified identifier is not a record type
The qualified identifier used in a record type declaration to build an
extended type must be a record type name.
\
268 Proper procedure cannot return a value
Only function procedures can return a value.
\
269 Maximum of range is less than minimum
\
270 Type guard only applicable to variable parameters and pointers
A type guard or an IS expression may only be used with variables which are 
pointers to record types or VAR parameters.
\
271 Implementation limit - maximum array dimension is 32
\
272 Receiver of type bound procedure call is of wrong type
A receiver variable must be of the type that the procedure is bound to ie.
a pointer type or a record type.
\
273 Type guard not extension of guarded variable
The type used in a type guard is not an extension of the static type
of the variable that is guarded.  This type guard will always be
false as the dynamic type of the variable can only be an extension
of its static type.
\
274 Cannot extend foreign record type
As records in other languages are implemented differently, gpo 
does not allow foreign record types to be extended.
\
275 Cannot use NEW on foreign objects, must use SYSTEM.NEW
The standard procedure NEW can only be used on Oberon objects,
i.e. records and arrays.  Any foreign objects which need space
allocated must call SYSTEM.NEW with the pointer variable and the
size required. 
\
276 Must have IS IN statement in non-Oberon module 
A foreign or interface "definition" module for Oberon must contain the IS IN 
statement to allow the object file for the module to be included at link time.
\
277 Incompatible keys for symbol files
When IMPORTing from various modules, repeated references to the same module 
are checked for the same version keys. Thus, for example, if module A imports 
from modules B and C, and each of B and C in turn imported from D, the two 
references to D must be consistent.   

You must determine which module(s) are obsolete, and recompile in the
appropriate order. Use of the -V (super-verbose) option of gpo is 
strongly recommended.
\
278 Wrong name in symbol file
The module name in the symbol file (quoted in the error message) is not the
expected one (that in the IMPORT statement). With the symbol file name 
normally derived from the module name, this will occur only if another file
has been renamed to the symbol file name. It is common to rename object files 
(or better still, use the -f option) when there are several alternative 
implementations, but you should never rename a symbol file.
\
279 Linker name is not unique
Since linker names are constructed from the first 11 characters of the module 
name followed by the first 28 characters of the exported procedure or variable 
name, it is possible for clashes to occur within a compilation unit, where the 
full names would not clash. Thus, for example, procedure 
	FilesMod001.WriteToLogfileAndStdError 
would produce the linker name
	FilesMod00_WriteToLogfileAndStd
This name would clash with the name formed for the procedure
	FilesMod002.WriteToLogfileAndStdOut
Clearly, avoidance of module and exported procedure / variable names with 
long common prefixes will prevent this problem. The problem does not arise 
for non-exported names, since gpo itself takes account of all characters of 
identifiers no matter how long.

Note that further clashes may arise at build time, due to names constructed
in independent compilation units. 
\
280 Implementation limit - WITH statement too deeply nested
gpo has a WITH statement nesting level of 20.
\
281 Cannot bind procedure to imported type
Type bound procedures may only be declared for types which are declared
within the current module. 
\
282 Size of open array type unknown
The parameter to the built-in function SIZE cannot be an open array type. 
\
283 Foreign and Interface modules cannot contain implementation code
A FOREIGN or INTERFACE module only declares constants, variables,
types and procedures which are exported.  It may not contain the 
implementation or body of any procedures or any module initialization
code.
\
284 Procedure types not compatible
Procedures with open array formal parameters which are declared in non-
interface modules may only be assigned to variables of procedure types
which are also declared in non-interface modules. 
\
285 Type-bound procedure must be bound to local record type
A type-bound procedure must be associated with a record type T declared in
the same module. The receiver may be either a variable parameter of type T
or a value parameter of type POINTER TO T.
\
286 EXIT not within a LOOP
The EXIT statement exits from the nearest enclosing LOOP statement, 
continuing execution with the statement after the LOOP. This EXIT statement 
is not within any LOOP.
\
495 Array is very large
gpo allows arrays whose size may well embarass virtual memory management,
file system capacity, or both. Since such a large size may be unintended, 
this warning is given for sizes greater than 16 megabytes.
\
496 Case statement has very low density
Of the range of values used by this CASE statement, less than 25% are actually 
referenced; since the compiler typically implements a CASE statement as a jump 
table, relatively large amounts of code may be generated. If the Oberon code 
can be expressed as IF statements without loss of clarity, more compact code 
will usually result.
\
497 Field of record more accessible than record type - changed
The field of a record type has been declared as exported when the record
type is read only export, or the field is exported (or read only exported) when
the record type is not.  The field export mode has been changed to the export
mode of the record type.
\
498 Symbols follow module end
It is legal to have further text following the END ModuleName. which must
terminate any compilation unit; however, since this may not have been
intended, this warning is issued.
\
499 Procedure is not called, assigned, or exported
Clearly, this procedure is of no use. This may be a valid state during
program development, or it may reflect a procedure no longer used. It may,
however, be a symptom of a mis-spelt reference to a procedure which
unfortunately happened to match another procedure name.
\
500 No EXIT from this LOOP
This LOOP is 'infinite' since there is no EXIT or RETURN within it. This
may be deliberate, but may be an omission. Note that EXIT escapes from only 
the innermost enclosing LOOP, so that an outer LOOP will still need an EXIT. 
By contrast, the use of RETURN forcibly terminates all loops, and the 
procedure in which they are enclosed.
\
501 Type guard will fail at runtime
Static type checking of the program has shown that this type guard will
fail when the program is run.
\
502 Dynamic type of record is not equal to static type of record
Static type checking of the program has shown that the runtime type of
this record is an extension of its static type.  According to the language
specification, the dynamic type of a record being assigned to must be
the same as its static type.  Therefore, this program will fail at runtime.
\
503 Browse comment in wrong place
A browse comment can only appear after an item which is exported, or a
module header.
\
504 Pointer not initialized on all paths
Static type checking of the program has shown that the pointer which is
dereferenced has not been initialized on all paths to this point, either
by a call to NEW or an assignment.
\
505 With Statement will produce runtime error
Static type checking of the program has shown that none of the options 
in this WITH statement will execute at runtime and there is no ELSE
clause, so the program will fail at runtime 
\
