Eiffel Home Page (Web) -- Getting started with Eiffel (local)

Levels of language description

Let's remind ourselves first of how the language is specified. The book Eiffel: The Language , the language reference, carefully distinguishes between three levels of description: syntax , validity and semantics . Their roles are clearly distinct:

Syntax defines the structure of software texts. A typical syntax rule states that an assignment starts with a Writable entity, continues with the symbol := , and ends with an Expression . This is a purely structural specification, saying nothing for example about the types of the Writable and the Expression .

Validity , applicable only to syntactically legal texts, defines required consistency conditions. A typical validity rule states that in an assignment the right-hand-side Expression must conform -- a property of its type, defined rigorously on the basis of inheritance -- to the left-hand-side Writable . Eiffel has about 75 validity rules; part of the language's originality is that these rules are of the " if and only if " form, not only telling you individual error cases ("this is valid only if … ") but also reassuring you that your text will in fact be valid if it satisfies the conditions listed exhaustively.

Semantics, applicable only to valid texts, defines the software's expected run-time behavior. A typical semantic rule states that an assignment replaces the value of its left-hand-side Writable by the value of the right-hand-side Expression at the time the assignment is executed, with precise rules on the different possible cases involving references, objects and simple values.

You may make an error at any of these levels:

Writing = instead of := for the assignment symbol is a syntax error.

Writing your_integer := your_real , with the types suggested by the names, is a validity error.

Calling a feature on a void target, violating a precondition, causing a division by zero, are semantic errors.

Syntax and validity errors will be detected by the compilation process. For semantic errors, you will rely on contract checking and on the debugging tools described later. Let's look now at examples of the first two cases.

A syntax error

To see what happens for a syntax error, replace the keyword is by ist in the first line of routine display of class PARENT (click the position immediately after the s and type a t .). Save the file by clicking the Save button or using CTRL- S . EiffelStudio parses the class as it is saving it, and finds the error:
The position of the error is highlighted in the class text.

To correct the error, just bring the mouse back to its location, remove the spurious t , and click Save again; also click Compile to make sure that the project is recompiled up-to-date.

You may wonder why the syntax error messages are not a little more verbose than just Syntax error . The reason is merely that Eiffel's syntax, being simple and regular, does not require sophisticated error messages; syntax errors usually result from trivial oversights. If you make a syntax error and the reason is not immediately clear, check the syntax summary in the appendix of Eiffel: The Language .

Avoiding "Gotcha" dialogs

This syntax error message also illustrates a user interface principle present throughout EiffelStudio. At ISE, we believe that you have better things to do than spending your days clicking on OK buttons. Almost all messages that may appear to signal errors, display warnings, or request confirmation are of one of two kinds:

Whenever possible, they give you two or more possibilities. A dialog with just one possibility is not much of a dialog. (We'll resist the temptation to be pompous here by recalling the original Greek meaning of " dia " in "dialog".)

If EiffelStudio cannot give two possibilities -- as in the case of an error message, for which it must let the user proceed after making sure the message has been seen -- EiffelStudio doesn't force you, like many of today's user interfaces, to acknowledge your sins by clicking an OK button. You simply correct the error and move on.

In the case of our syntax error there is an OK button and you may click it, but you don't have to. It is there mostly to avoid troubling people (almost everyone, that is) who are used to the "Gotcha!" dialogs of the dominant user interfaces. Once you get used to the EiffelStudio style, you won't bother clicking OK for a syntax error: you will correct the error, and when you click Save again the dialog will go away like a bad dream.

A validity error

A validity error is a violation of one of the validity constraints given in Eiffel: The Language . Every such constraint is identified by a four-letter code of the form V XXX (the first letter is always V ).

A validity error will produce a precise error message, which includes the validity code. Although short, the error message is usually sufficient to find out what the error is. If not, you can get the complete rule, straight from the book.

To see this mechanism at work, let us introduce a validity error. There is in fact one ready for you in class TESTROOT . Target a Development Window to this class; at the end of its text, just before the final end , you will find the following comment line:

-- inv: INVALID

If uncommented, this is a declaration of a feature of type INVALID . A class called INVALID indeed exists in file invalid.e of the root cluster, but it contains a validity error. To see what it is, remove the initial double-dash -- in the above line from class TESTROOT so that it is not a comment any more.

Click Save , then Compile . Compilation starts but after a few degrees it stops with an error message that appears in the bottom Context Tool (you may have to do some resizing to see it in its entirety):

As the error message indicates, you have (shame on you) violated the validity rule VUAR , which requires the number and types of actual arguments in a routine call to match the number and types of formal arguments declared in the routine.

One of the interesting properties of the error message is that everything in color is clickable : class name, feature name, but also the error code. This means that you can start a Pick-and-Drop on any of these elements to find out more.

For example, to see the exact context of the error, pick-and-drop the name of the affected feature, display -- appearing on the fifth non-blank line, after Feature: -- and pick-and-drop it to the top Text window. (As you remember this means: right-click on it and release; move the mouse to the text window, without clicking any button; right-click again. During the move the cursor shows a cross, the symbol for features.) This displays the erroneous feature:

Note on this display a special property of Pick-and-Drop when its source is a feature name appearing in a validity error message: the instruction that causes the error is highlighted.

In the error message in the Context Tool, the error code itself, VUAR , is also clickable. Assuming the message was not sufficient to understand the error, you can use it to start a Pick-and-Drop. Do this now, by picking that code and starting to move the mouse, but not dropping yet:

The icon shape for such information elements is a question mark ? . If it is not on a droppable target, as in the bottom Context Tool, that icon will be crossed. In principle the place to drop is the Explanation hole in the Project toolbar, the only one that remains highlighted during the Move step of Pick-and-Drop:

As is often the case when dropping into a specific hole, you don't need to shoot straight; dropping the pebble anywhere in the Editing Tool has the same effect as dropping it into the Explanation hole:

The result is to display the complete text of the violated rule, straight from the pages of Eiffel: The Language .

The rule has several clauses, numbered. Since the error message showed the error code as VUAR(1) , the violated clause is the first; this convention of showing the clause number in parentheses applies to all multi-clause validity constraints.

To correct the error the easiest is to go back to class TESTROOT and reinstate the comment symbol - - (two consecutive dashes) on the erroneous line. Save and compile to continue with a valid system.