From: eifcom@cs.vu.nl (Robin Hos + partner)
Newsgroups: comp.lang.eiffel
Subject: language definition versus library
Date: 6 Apr 92 08:35:36 GMT
Organization: Fac. Wiskunde & Informatica, Vrije Universiteit, Amsterdam

We, two students of the Vrije Universiteit in Amsterdam (Netherlands), are
studying the Eiffel language. While examining the eiffel language, the library
shipped with the Eiffel compiler version 2.2B and running some test programs,
a couple of questions came to our minds.


1) A feature is associated with another feature whose declared type is a 
   generic parameter.

   Library class linked_list reads:

   feature

	....

        first: T is
                        -- Item at first position
	....

   -- Information about cursor position

        item: like first is
                        -- Item at cursor position
	....

   The eiffel manual reads on page 74:
     - anchor is the final name of a feature of C, whose declared type
       is a class type.
     The second part of the rule implies that the anchor's type may
     not be an expanded type or a Formal_generic_name, and that its
     declared type may not itself be an association type. (As a
     result, entities declared by association, like entities of class
     types, will have references, not objects as their values.)

   Generic parameters of a class are not inherited and a generic
   parameter can not be redefined. To us, the use of a declaration by
   association seems useless here. The library uses this construction
   consistently, anyone know why?


2) A feature is associated with another feature whose declared type is
   a boolean.

   Library class bool_string reads:

     item (i: INTEGER): BOOLEAN is
	.....

     put (v: like item; i: INTEGER) is

   Like above the anchor's type is not a class type.


3) A multiple inherited feature is redefined from several parents

   Library class string reads:

     inherit

        INDIRECT [CHARACTER]
                redefine
                        generics,
                        equal;
        HASHABLE
                redefine
                        equal;
        COMPARABLE
                rename
                        lt as obsolete_lt,
                        eq as obsolete_eq
                redefine
                        equal;

   The manual doesn't describe this situation. Intuitively, this means
   that it is possible to inherit multiple effective features and then
   provide one new effective feature in the child class.

   This construction seems usefull, but if it would be allowed, it
   introduces other questions. What if one of the equal's in the above
   example would not have been redefined? Can you rename several
   features from one parent to the same final name and redefine them all
   with only one name in the redefine clause? Is this is allowed, what
   kind of constructions can you make, combining define are redefine, to
   put several deferred and effective features in one final feature?


We also have two other questions:

4) Feature definition

   In the manual "Eiffel: the language" page 49 feature definition is
   described. We quote the first part of the definition rule:

   "A class C may use an effective feature f to define one or more deferred
   features f1, ..., fn inherited from respective parents B1, ..., Bn, if
   and only if the following conditions are satisfied. ................."

   The rule doesn't say anything about the parents B1, ..., Bn. I.e. the
   rule doesn't specify that all Bi must be different or not. Note that
   the compiler doesn't accept the case that some Bi and Bj are the same
   parent.

   Must all Bi's be different parents ?


5) Like to like

   The compiler accepts features who are associated with features which are
   themself declared as an association type. Contradicting the manual (see
   topic 1).


If one of the language constructs changed between version 2.2 and 3.0,
please let us know (all we know is version 2.2). All suggestions are
welcome.

Regards,

                                Robin Hos and Walter Slegers
                                (eifcom@cs.vu.nl)


--
--
Robin Hos                               \    /  |   |   Vrije Universiteit
Walter Slegers                           \  /   |   |   Amsterdam
Email: eifcom@cs.vu.nl                    \/    |___|   Netherlands