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

NICE Language Committee: anchored

From swissoft.h.provi.de!eiffel@Hannover.POP.DE Fri Oct 13 10:20:00 1995
Date: 13 Oct 1995 15:48:00 +0200
To: bertrand@eiffel.com
Cc: tynor@atlanta.twr.com
Subject: VIP - addendum to anchors and genericity
X-Mailer: XP v3.02 R/C4131
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 3701
Status: RO
X-Lines: 121

Dear Bertrand, dear Steve,

this is an addendum to my VIP contributions about anchored types
and constrained genericity. The definitions and rules given below
are those I used in Eiffel/S 2.0. I do not necessarily suggest
that these rules (or similar ones) should be made part of the
language definition - it's more a report on how one particular
implementation handles the problems addressed in early VIP papers.

With best regards,
    Michael
-----------------------------------------------------------

Definition 1:

A type T _contains anchors_ if and only if

    a) T is of the form 'like anchor'
  or
    b) T is of the form 'C [G1, ..., Gn]' and
       at least one of the Gi contains anchors.

Rule 1:

A declaration of the form 'e : like anchor' is valid, only if
the type of 'anchor' does not contain anchors.
-----------------------------------------------------------

Discussion:

A weaker version of Rule 1 is already part of VTAT (the type
of 'anchor' may not be an anchored type itself). However,
declarations of the form

        a : like b
        b : ARRAY [like c]

are currently allowed (even for c = a and for c = b). Rule 1
makes these declarations invalid. I considered to implement
a weaker rule - only disallow cyclic dependencies - but that
doesn't solve the following type of problem:

        f (arg : ANY) : ARRAY [like arg] is do .. end

        g : like f is do .. end

Here the type of 'g' is indirectly anchored to the argument
'arg' of 'f' - this is weird and it is easy to construct
arbitrarily weird 'anchor webs' by combining anchored declarations
with genericity.

Rule 1 makes all these weird things impossible and I believe that
it is not too restrictive in practice.

[Alternative: exclude cyclic dependencies (taking genericity into
 account) and add a rule which makes it impossible that a formal
 argument or the type of one feature is indirectly anchored to
 a formal argument of some other feature.]
-----------------------------------------------------------

Definition 2:

A formal generic parameter G of a class C _appears_ in a type
T in C, if and only if

    a) T is G
 or
    b) T is of the form 'B [T1, ..., Tn]' and G appears in
       at least one of the Ti.

Definition 3:

A formal generic parameter G1 _depends directly_ on a formal generic
parameter G2, if and only if

   G1 is a constrained generic parameter with constaint
   type C (i.e. G1 -> C) and G2 appears in C.

A formal generic parameter G1 _depends_ on a formal generic
parameter G2, if and only if there exists a formal generic
parameter G such that G1 depends directly on G and G depends
on G2.

Rule 2:

A formal generic parameter G may not depend on itself.

Rule 3:

The constraint type of a constrained formal generic parameter
may not contain anchors.

-----------------------------------------------------------

Discussion:

Rule 2:

Excluding cycles in the declaration of formal generics is clearly
necessary. A declaration of the form

        C [G1 -> ARRAY [G2], G2 -> LIST [G1]]

does clearly make no sense.

Rule 3:

This rule is in part necessary to support rule 2 because a declaration

        C [G -> ARRAY [like anchor]]

may be cyclic (anchor = Current or G appears in the type of anchor).
Although cycles could be detected by the compiler, I preferred to
use a simple rule. It's also questionable whether anchors in constraints
are useful and especially whether such declarations can be understood
by anybody else than the class designer himself.
-----------------------------------------------------------

SwisSoft, Michael Schweitzer      Geismar Landstr. 16  D-37083 Goettingen
Fax : +49 551 770 35 44           email : eiffel@swissoft.h.provi.de