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.



15.1 : Traditional and nontraditional aspects

Even a particularly skilled programmer will have to deal with compiler error messages at some point. Upon initial encounter, these messages often seem confusing. However, with practice their meaning will become clear. The Aldor compiler tries to give messages which are reasonably brief, but still informative. Although more detailed messages may be useful to novice programmers, most beginners quickly move past the initial desire for more detailed messages. The following paragraphs describe the components of the messages produced by the Aldor compiler.

Format of Aldor error messages

Each message produced by the Aldor compiler is assigned a line and a column position based on the place in the source text of the program associated with the message. Then, for each source line for which messages have been generated, the compiler reports the source line, a line containing pointers to the column assigned to each message, and a description of each message which appears for the source line.

Each source line is reported by showing the source file name in which the line appears (enclosed in quotation marks), the line number within the file, followed by a colon (:), and then the text of the line itself.

After the source line is reported, the next output line contains a circumflex (^), used as a caret below each column at which an error was detected. Periods (...) are used to fill in the spaces between the carets.

Each error that appears on a line is then precisely located and shown in a format which can be used to quickly locate and fix the error. For each error, the line and column number are printed first, enclosed within square brackets ([ ]), then the severity of the error is indicated by one of the keywords Fatal, Error, Warning, or Remark appearing in parentheses. Following the severity of the error is the text of the message, which may include references to parts of the source text, or references to types or other data structures used to compile the program.



15.2 : Example showing Aldor messages

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)

Figure 15.2: Error messages for "error0.as".


"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'.


Figure 15.3: "error1.as" -- A program containing fewer mistakes.

#include "aldor.as"
#pile

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


Figure 15.4: Error messages for "error1.as".

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


Figure 15.5: "error2.as" -- A program which compiles

#include "aldor.as"
#pile

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




15.3 : Some common error messages

This section explains some error messages likely to be seen by new users.

Compiler error messages do not always explain the real nature of the problem. This statement is true in general, and not only for the Aldor compiler. Compilers analyse programs on the basis of more or less rigid syntactic rules, and they can become enormously confused by a missing character, or mis-spelled word.

What follows is a collection of `mysterious' messages (or, at least, messages which are puzzling to new Aldor programmers), generated by Aldor.

This is probably a message that will occur only once -- it indicates that Aldor has not been set up properly.

See also section 27.14

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:

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.

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:

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

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:

See also part II.

See also section 16.2

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.

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:

gives the error message:

See also chapter 24.



15.4 : Common pitfalls

This is a collection of mistakes frequently made novice Aldor programmers. A subclass of this consists of common mistakes for programmers from other languages, such as C, C++ and Fortran. It is important to be able to recognize situations where such mistakes occur, so that you can understand the compiler's error messages.

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.

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.

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.

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.

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 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:

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):

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.



15.5 : Controlling compiler messages

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.



15.6 : Interactive error investigation

In most cases, the error messages will give enough information for the programmer to determine what is wrong with a program. In some cases, however, extra detail is required. Rather than print many lines of debugging information for each error, the Aldor compiler gives messages of moderate length and allows the programmer to get more information interactively.

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
-------------------------------------------------------------------

The interactive error inspector allows the following commands:

  
helplist the commands, with descriptions
showshow the current node
meansshow the possible meanings of the current node
useshow how the current node is used
semanshow the extra semantic information for the current node
scopeshow information about the current scope
  
upuse the parent as the current node
downuse the 0th child as the current node
nextuse the next sibling as the current node
prevuse the previous sibling as the current node
homereturn to the original node
wherereturn the source position of the current node
  
getcomsgget information on the current message
notesshow the notes associated with the current message
mselect iselect message i to be the current message
mnextselect the next message in the list
mprevselect the previous message in the list
msgdisplay the error message again
niceshow with pretty printed form
uglyshow with more detailed, internal form
  
quitexit the compiler, showing all messages so far
  

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.



15.7 : Selecting error messages

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

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

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

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.



15.8 : Error messages and macros

When an error occurs in the processing of program text which involves a macro, it is sometimes useful for the error message to point to the macro invocation but, at other times, it is more useful for it to point into the body of the macro, to the location where the error was detected. The command

instructs Aldorcmd to point to the text of the macro, while the command

instructs Aldorcmd sharp to point to the macro invocation.

There is no mechanism for instructing Aldorcmd to point to the invocation of a macro which appears in the body of another macro.



15.9 : Error messages and GNU Emacs

GNU Emacs offers several commands for compiling and debugging programs. Among these are ``M-x compile'', which can be used to compile Aldor programs. By default, M-x compile issues the command ``make'', in a separate process, but the command may be changed to any other Unix command, including any command line which invokes the Aldor compiler. Output from the command goes to the buffer *compilation*. The format of the error messages produced by the Aldor compiler is then understood by the command ``C-x `'', which finds the next error message in the *compilation* buffer and displays the source line which produced the error.



15.10 : Using an alternative message database

It is possible to have the Aldor compiler use an alternative message database. This is done via the -Mdb command line option. Thus, a command script can cause the compiler to use a database of messages translated to some other language, or which give a different level of detail.

The messages which have been built into the compiler were derived from the database samples/comsgdb.msg. A replacement message database must provide messages for all the message tags in that file.

The message database file uses the X/Open format. The Aldor tools directory provides the source code msgcat.c to create a program to convert files of the form comsgdb.msg into X/Open message catalogs, but any tool which produces databases in that format can be used.

Once a new message database file has been created, it can be placed in any directory which is normally searched for executable programs. If the database is called newcomsgs.cat, for example, then the compiler argument ``-Mdb=newcomsgs'' will find it.


Previous Home Contents Next