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
|