Previous

Home

Contents

Next

Chapter 15: Understanding messages

1 Aldor error messages

2 Example showing aldor messages

3 Some common error messages

4 Common pitfalls

5 Controlling compiler messages

6 Interactive error investigation

7 Selecting error messages

8 Error messages and macros

9 Error messages and GNU Emacs

10 Using an alternative message database

The Aldor compiler may display messages of various sorts, including errors, warnings and remarks about the program being compiled. This section is a guide to understanding the format and controlling the generation of Aldor messages.

A complete list of the messages produced by the compiler may be found in chapter 28.

The message format described in the previous section will be illustrated by examining the error messages produced by compiling the file error0.as shown in figure 15.1. The command Aldorcmderror0.as produces the messages shown in figure 15.2.

The first line of this message indicates that the message was generated from line 4 of the file error0.as. The next lines specify that errors were detected at columns 16 and 19 on this line. The carets indicate that the first error reported on this line is due to the operator => and that the second error reported on this line resulted from the symbol 1. In addition, these are the second and third messages, respectively, which were encountered during the compilation of error0.as.

The next message shown is actually the first detected by the compiler. It is a ``Warning'' which complains of a missing ``;''. There is also a hint which suggests that piling has been used incorrectly. However, since the declaration ``#pile'' was not included in the file, piling syntax (see sectino 24.3) is not being used.

Let's add the declaration ``#pile'' to error0.as and call the updated file error1.as, shown in FigureError1In. Compiling this file produces the messages shown in FigureError1Out. Now there is a single error message at line 6, which complains that no meaning can be found for the operator ``f''. There is certainly no declaration for ``f'' in error1.as. This operator should in fact be ``factorial'', and not ``f''. After making this change (shown in FigureError2In), the file will compile cleanly.

This example was compiled using the default message options as described in figure 15.3. The compiler's message options determine what kinds of messages the compiler will generate.

Figure 15.1: "error0.as" -- A program containing mistakes.

#include "aldor.as"

factorial(n: Integer): Integer ==
       n <= 1 => 1
       n * f(n-1)

"error0.as", line 4:         n <= 1 => 1
                     ...............^..^
[L4 C16] #2 (Error) A value is needed but '=>' does not produce one.
[L4 C19] #3 (Error) There are no suitable meanings for the operator '1'.

"error0.as", line 5:         n * f(n-1)
                     ........^...^
[L5 C9] #1 (Warning) Suspicious juxtaposition.  Check for missing ';'.
Check indentation if you are using '#pile'.
[L5 C13] #4 (Error) There are no suitable meanings for the operator 'f'.

#include "aldor.as"
#pile

factorial(n: Integer): Integer ==
        n <= 1 => 1
	n * f(n-1)

"error1.as", line 6:         n * f(n-1)
                     ............^
[L6 C13] #1 (Error) There are no suitable meanings for the operator 'f'.

#include "aldor.as"
#pile

factorial(n: Integer): Integer ==
        n <= 1 => 1
        n * factorial(n-1)

See also section 27.14

• No meaning for integer-style literal `xxx'
• No meaning for string-style literal `xxx'
• No meaning for float-style literal `xxx.xx'

Unlike traditional programming languages, in Aldor there is no built-in knowledge about the meaning of numeric or string constants. Every domain can export an interpretation for these constants, with the advantage that you can define your own methods for interpreting them. The standard Aldor library contains some standard domains exporting interpretations for these constants, but you must explicitly import these domains in the scope of your program. So in your program you need to say:

import from SingleInteger;     or     inport from Ingeter;

to specify if you want to use the machine representation or the infinite precision representation for integer-style literals such as 2, 3, 4, ... For string-style literals, such as dog and cat, you can import from the String domain, and for float-style literals you can import from SingleFloat (single-precision hardware floating point), DoubleFloat (double-precision hardware floating point) or Float (arbitrary precision software floating point). See also section 5.2.

• No one possible return type satisfies the context type

Aldor is a strongly typed language. This means that the type of each expression forming the program is determined during the compilation process. The following example shows a typical situation in which this message occurs:

#include "aldor"

foo():Integer == 1;

b: SingleInteger == foo();

Compiling this example with the option -M2 (full error messages), gives:

b : SingleInteger == foo()
.....................^
[L5 C22] #1 (Error) No one possible return type satisfies the
context type.
  These possible return types were rejected:
          -- Integer
  The context requires an expression of type SingleInteger.

b is a constant whose type is SingleInteger, so on the right-hand side of the definition an expression of the same type is required. When the compiler searches for all the possible return types for foo(), it finds that the unique possible type, Integer doesn't satify SingleInteger. Note that a function could be overloaded, which is why the message says: ``No one possible return type...''. To fix this problem, foo can be overloaded with a new definition, or the result of foo can be coerced to a SingleInteger as in:

b: SingleInteger == foo()::SingleInteger;

See also part II.

• No meaning for identifier 'domain'
  • If you are defining domain in the same file, are you sure that the spelling for domain is correct? (Remember that Aldor is case-sensitive: Integer and integer are two different identifiers!)
  • If domain is from an external library, for example mylib, did you include the #library statement in your file? For instance:

    #library MyLib "mylib"
    import from MyLib;
    

    In this case, if you get the error message in the import statement and the symbol that you are importing has been defined in a #library statement, then check the following rules:
    1. If the library is a library created with ar (with suffix .al), than you must not write the suffix. This is the case, for mylib -- it corresponds to the file libmylib.al
    2. If the library is a .ao file, than you must use the .ao suffix in the #library statement.

See also section 16.2

• Argument 1 of `test' did not match any possible parameter type

If the test is for equality, in an if statement, are you sure that you are using = and not ==? This can be a frequent mistake for C/C++ programmers. The message says ``Argument 1 of `test'...'' even if there is no explicit call to the test operator, because in some contexts, such as an if statement, the test operator is implicitly applied.

• `Syntax error' at the beginning of a line

If you are sure about the correctness of the displayed line, look at the previous line. A macro definition using ==> and not ending with ; can often cause this error. For example, compiling the following statements from the file myfile.as:

#include "aldor"
-- Not using `#pile'.

SInt==>SingleInteger

import from SInt;

gives the error message:

"myfile.as", line 6: import from SInt;
               ^
[L6 C1] #1 (Error) Syntax error.

See also chapter 24.

These symbols have completely different uses in Aldor. The ==> (long arrow) symbol is used to define a macro (you can also use the form ``macro ...''), see chapter 12, whereas the => (short arrow) symbol is used as an early exit in a sequence, see section 5.10.

• `=' and `==', `=' and `:='

The = symbol is usually used as an equality operator (but can be overloaded by user programs). The == (double-equal) is used to define constants -- categories, domains, functions and values are all Aldor constants. The double-equal symbol is sometimes referred to as the ``very-equal'' symbol for obvious reasons. The := operator is used for assignments.

• Using `_' as a separator in identifiers

The _ (underscore) symbol is used as an escape character in Aldor -- thus the identifiers list_of_integers and listofintegers are exactly the same. For this reason, to prevent ambiguities, we suggest using capital letters, instead of _, to separate words in identifiers, as in listOfIntegers.

• Missing `;' at the end of a macro definition

Unlike other languages, such as C, the Aldor preprocessor requires that macro definitions end with a ; (or a newline, if you are using #pile. The current error message is very misleading, because it complains about a syntax error at the beginning of next line.

• Undefined symbol _INIT__xxx referenced from text segment

This is a message generated by the C compiler (cc, gcc, xlc, etc.) that Aldor is using on your platform to generate stand-alone executable files. Everything in the compilation process of the Aldor program succeeded, but something went wrong in the final linking step.

One common cause of this kind of problem is compilation using another library, as well as/instead of the standard Aldor library, without letting the compiler know about the other library. When you include a .al library, you should add -1libname to the command line. See chapter 16 and, in particular, section 16.2 to understand how to use other libraries with Aldor. Some points to note when compiling are:

• If you have included the file adordemo.as, you will need to add -laldordemo to the command line.
• If you want to use a domain from mylib (a library containing definitions of some domains), you should include the following lines in your Aldor program:

  #library MyLib "mylib"
  import from MyLib;
  

  (Note that any identifier may be used in place of MyLib.) When calling the compiler, you need to include the -lmylib option among the parameters; for example:
  % Aldorcmd -lmylib myprog.as


• User program with the same name as a library file

If you create a .as file with the same name of a library file, it won't compile. The compiler will issue a warning message if there is such a name confict. For example, there is a file in libaldor with the name pointer.as; suppose that your file is also named pointer.as and contains the line #include "aldor". When your file is compiled, you will get a warning, followed by an error message relating to the file aldor.as:

"#1 (Warning) Current file over-rides existing library in
`/aldor/base/rs3.2/lib/libaldor.al'.
"/aldor/base/rs3.2/include/aldor.as", line 66:
        import from FormattedOutput;
....................^
[L66 C21] #2 (Error) No meaning for identifier `FormattedOutput'.

The easiest way to view the names of the files in a library is usually to use a command provided for that purpose by your operating system -- for example, the ar command in Unix (see section 16.2 for an alternative):

cd $ALDORROOT/lib
ar vt libaldor.al
ar vt libfoam.al
ar vt libaldordemo.al

The compiler will issue a warning message if the name of your file is used by any library needed for compilation of the file. If you are recompiling a library, then the warning can safely be ignored.

The types of messages returned by the Aldor compiler are controlled using the -M option, which takes an argument identifying the kind of message information to display. Preceding any message option with ``n-o'' negates that option, so -M no-details will suppress the details associated with a compiler message. A complete listing of the message options can be found in section 27.12.

The default compiler message options

The default message option used by the Aldor compiler is -M 2, which is equivalent to the following collection of options: -M number, -M sort, -M warnings, -M source, -M details, -M notes, -M mactext, -M abbrev and -M human.

The option -M human indicates that the compiler messages are to be read and interpreted by a human user, as opposed to a computer program such as Emacs or XALDOR.

The -M number option enumerates the order in which the compiler messages were encountered. An ordinal #n appears after the bracketed line and column values. The default option -M sort shows the compiler messages sorted by the order in which they appear within the file. Using -M no-sort instead causes the messages to appear in the order in which they are encountered by the compiler, which may be different from their order in in the program.

The -M warnings option will display the compile time warnings which do not prevent a successful compilation. When the option is changed to -M no-warnings then those messages, which are only advisory in nature, are suppressed.

The compiler normally displays the source text which caused each message. However, using -M no-source displays only the compiler message with the line and character location without showing the source text.

Some compiler messages may have notes associated with them which cross reference other compiler messages having a similar or identical meaning. They are produced by the option -M notes.

Compiler messages abbreviate the data types which are contained within the text of the message, when the option -M abbrev is used. To expand the type names, use the option -M no-abbrev.

The -M inspect option (not to be confused with -G loop) must be given if interactive error investigation is desired. Then, whenever the compiler detects an error, it stops and enters a debugger or ``break loop''. The break loop gives the programmer access to information such as the types of variables and the names in scope. An example using the interactve loop is shown in figure 15.6.

Figure 15.6: Interactive Error Investigation

%aldor -Minspect error3.as
"error3.as", line 33:           -- lbi-b+zi or lbb-b+zb: ambiguous
        b := left(b, z)
.............^
[L33 C14] #1 (Error) There are 2 meanings for the operator 'left'.
Meaning 1: (Boolean, Integer) -> Boolean
Meaning 2: (Boolean, Boolean) -> Boolean

"error3.as", line 34          b := left(i, i)        -- no meaning
                      ..................^
[L34 C19] #2 (Error) Argument 1 of 'left' did not match with any
possible parameter type.
    The rejected type is Integer.
    Expected type Boolean.

A# compiler break--------------------------------------------------
::: up
left(b, z)
::: down
left
::: next
b
::: means
1: Param b : Boolean

::: next
z
::: means
1: LexConst z : Integer
2: LexConst z : Boolean

::: quit
-------------------------------------------------------------------

When the options -M inspect and -M no-human are both given, the interactive break loop operates under the same mode as the XALDOR debugger. Refer to chapter 20 for more detail on XALDOR.

The Aldor compiler is organized in such a way that messages may be replaced, enabled, and/or disabled from the command line.Messages are identified by a name tag, e.g. ``ALDOR_W_CantUseLibrary''. The name tags of all messages used by the compiler may be found in the catalog of error messages in chapter 28

Once the name of a particular message is identified, the command

aldor -M msgname input.as

can be used to enable the message msgname if it is otherwise disabled. Conversely, the command

Aldorcmd -M no-msgname input.as

will disable the message msgname if it is otherwise enabled. Normally, the messages classified as warnings are enabled, while those classified as remarks are disabled.

The special message name ``warnings'' can be used to enable or disable all warning messages, and the special name ``remarks'' can be used to enable or disable all remarks. ``Error'' messages cannot be disabled.

In addition to selecting error messages by name, it is possible to use the command

Aldorcmd -M emax=n

to specify the number of error messages will be reported before Aldorcmd gives up and stops processing the input file. This number is initialized to 10.

Previous

Home

Contents

Next