Implementation of primitive types in Eiffel/circular definitions in library source

Question

I am new to Eiffel and I am trying to understand how the "primitive" types (e.g, INTEGER_32, REAL_64, etc.) are implemented. I am confused by what appears to be a circular dependency in the EIFFEL libary class source files.

Primitive types are implemented as "expanded" versions of a non-expanded parent class. For example, INTEGER_32 is an expanded child of INTEGER_REF_32. (Note that "expanded" does not mean "an instance of". An expanded class is a class, not an object.)

An INTEGER_REF_32 contains an instance of an expanded INTEGER_32 within it. It makes sense that there must be an expanded integer somewhere within an INTEGER_REF_32 object, but here that means that the parent contains an instance of its child.

It gets more confusing when you look at the definitions of the features:

Within INTEGER_32, the feature/method named "as_integer_64" is redefined simply as "Result := Precurser", where Precurser means to use the parent's feature. In the parent, which is INTEGER_REF_32, "as_integer_64" is defined as "Result := item.as_integer_64", where "item" is the expanded INTEGER_32! In other words, the child calls its parent's feature, and the parent calls the child's feature. I am also puzzled why the expanded version explicitly redefines "as_integer_64" with what would appear to be an equivalent definition.

I expected to see implementation details for primitive types terminate with some indication that certain features are internally defined. Instead I found these circular definitions. Obviously the compiler knows more about the primitive types than what appears in the source text files. Does the compiler ignore the source text when it sees a primitive type it knows about, or does Precurser take on a different meaning in this context? Is the redefinition some sort of hint to the compiler, or something to keep the parser happy?

Answer 1

One of the reasons to have recursive definitions of the features in basic types is reusability. The detailed dicussion can be found in this paper (not sure it is available online):

Alexander V. Kogtenkov. Implementation of Primitive Types and Reusability. – Proceedings of the WOON’98 International Conference, St. Petersburg, 1998.

In short, if a basic class is used as an ancestor of some other class, this class inherits all the features like item, + and so on. The feature declarations are taken from the basic type as well. Because they are defined using feature calls on the basic type, the compiler knows how to generate the code.

Answer 2

Actually, if you look at the source code of INTEGER_32, you will see that all routines are implemented as `built-in', meaning that an Eiffel compiler is providing an implementation for those features.

Due to historical reasons in the design of EiffelBase (now known as FreeELKS), we have two classes for each basic types: X and X_REF. If we had to redo the core library without having to worry about backward compatibility, we would only keep X. There is no need for the X_REF class. Think of the X_REF class as a CELL [X] data type, i.e. a wrapper around X.

Now the Eiffel Software implementation of those builtins is very specific. It looks strange to use Precursor but this is done to allow old code patterns to work even though those are not allowed by the specification anymore. Again, if we had to drop backward compatibility, we would keep the implementation truly builtin and not show what the compiler would actually do.

Per se, there is no real recursive definition. In INTEGER_32_REF, `item' is treated as an attribute of type INTEGER_32, and in the descendant, it is treated as a query returning itself. This is why one should ignore that the INTEGER_32_REF class even exists, it is merely a CELL [INTGER_32_REF].