This site contains older material on Eiffel. For the main Eiffel page, see http://www.eiffel.com.

Precursor construct: the revised formal proposal

The Precursor mechanism is a recently introduced Eiffel construct The mechanism was proposed in mid-1997 (see credits at the end) to the language committee of NICE, the Nonprofit International Consortium for Eiffel, and formally approved by the committee in a vote of October 1997.

To understand this description you should have read the companion document presenting an informal description of the mechanism.

The rest of this document contains the formal description of the mechanism in a form meant for adoption by the NICE language committee. A section below describes the differences brought to the mechanism as a result of one year's use of the Precursor mechanism. These differences are minor and the earlier syntax is still supported by ISE Eiffel.

New reserved word

(To be added to list in "Eiffel: The Language", page 553.)

Precursor

Syntax change

Page 342, definition of Unqualified_call (previously Entity [Actuals]) becomes

Unqualified_call == Feature_of_call [Actuals]

with the new construct definitions

Feature_of_call == Entity | Precursor
Precursor == Precursor [Parent_qualification]
Parent_qualification == "{" Class_name "}"

Validity changes

Note (not subject to vote): everything could be done within VUEX, page 368. We have found it more clear to introduce two new constraints. In VUEX, page 368, replace condition 1 by

Unqualified_call

With the new validity rule VUNQ

Unqualified_call

1. Its Feature_of_call is the final name of a feature of C.

2. Its Feature_of_call is of the Precursor kind.

and the new validity rule VUPR:

Precursor

1. It appears in the Routine_body or the Rescue clause of the declaration of exactly one routine r of C.

2. If the Parent_qualification part is present, its Class_name is the name of a parent P of C.

3. The declaration of r in C is the redefinition of a routine that has exactly one version inherited by C as effective in the set of Parent types of C, restricted if case 2 applies to those having P as their Class_name.

Semantics change

Insert a new section on page 345 between 21.8 and 21.9:

Precursor calls

A call of the Precursor form, that is

Precursor (...)

Precursor {PARENT} (...)

may only appear in the redefinition of a routine r. The original version of r in the parent is known as the "immediate precursor".

In this case the feature of the call, fname, is the immediate precursor.

Also, the next section (21.9) should begin

target_value

Precursor

Note

(This note is not part of the proposal.) Since Object-Oriented Software Construction, second edition (Prentice Hall, 1997) uses double braces, as in {{PARENT}}, rather than single braces as in {PARENT}, it may be desirable for compilers to accept both forms. (ISE note: this is the case with ISE Eiffel.)

Differences with earlier version

(This note is not part of the proposal.) The present version is the one implemented in ISE Eiffel 4.3. The differences with the original proposal are:

Syntax: the Parent_qualification, if present, now appears after the Precursor keyword. The other order is still supported, so no incompatibility should result. Reason for the change: better consistency with other uses of braces in the syntax and the dominant Eiffel style of "qualified before qualifier" and "most important information first" (LL-like style).

Validity: shortening and rewriting of the validity constraint. Purposes: simpler, more clear definition; taking care of some special cases that had been overlooked in the initial discussion. Also, permitting the use of Precursor not only in a Routine_body as before but also in a Rescue clause.

Web page cosmetics: more systematic use of colors (different colors for Syntactical constructs and for actual Eiffel text examples.

The validity change has been discussed by the language committee and other experts and seems to enjoy consensus so far. The syntax change has not yet been discussed widely.

Credits

The Precursor proposal was put together and presented to NICE by Bertrand Meyer of ISE but the language construct is the result of collective work. The contributions of the following people are gratefully acknowledged (please signal any omissions): Éric Bezault, Roger Browne, James McKim, Xavier Le Vourch, Bertrand Meyer, Frieder Monninger, Steve Tynor, Dino Valente, Kim Waldén. In addition the validity change benefited from comments by David Hollenberg and Alexander Kogtenkov.