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

NICE Language Committee: ms-vncc-3

From Michael Schweitzer
Date: Tue, 5 Apr 94 14:33:26 +0200
To: bertrand@eiffel.com
Subject: MS-VNCC-3
Cc: tynor@atlanta.twr.com
Content-Length: 3705
Status: RO
X-Lines: 122

Dear Bertrand and Steve,

I think I just sent off a mangled version of Michael's
proposal. So here it is again -- hopefully intact
this time.

Sorry,
Robert

To   : Bertrand Meyer, Steve Tynor

-----------------------------------------------------------
Key   : MS-VNCC-3
Title : Conformance of NONE to formal generics and expanded types.
-----------------------------------------------------------

Discussion:

VNCC-3 (page 219) states that NONE conforms to every reference
type. My question is: does NONE conform to a formal generic?

Let me give an example:

        class HASH_TABLE [G, KEY -> HASHABLE]

            ...

            put (x : G, k : KEY) is

                require
                    valid_key : k /= Void       -- The problem is here!
                do
                    ...
                    h := k.hash_code            -- Illegal if 'k' is Void.
                    ...
                ensure
                    ...
                end

The problem is:

    If NONE does not conform to the formal generic `KEY' then
    the precondition is invalid. But then we cannot write
    "k.hash_code" in the body since we cannot guarantee that
    'k' will not be void.

I believe that this is a common situtation. One must at least
be able to restrict an actual argument to "not Void" in normal
classes and in generic classes (a similar argument applies
to postconditions: ensuring that the result is not void).
I believe that we all use this frequently (just examine your
libraries). But my understanding of the conformance rules is
that indeed NONE does not conform to a formal generic, since
a formal generic may stand both for a reference type and for
an expanded type and NONE only conforms to reference
types (VNCC-3).

Proposal(s):

There are several ways to resolve this problem:

1)  You may feel that it isn't a problem at all: it is not
    useful to test whether an entity of formal generic type
    is void.

2)  The rules for the equality (and inequality) operator
    are extended by explicitly saying that the expressions

        e = Void, Void = e, e /= Void, Void /= e

    are also legal in the case that 'e' is of formal generic
    type.

3)  The conformance rule VNCC-3 is changed to

        3 : V is NONE.

    This would have the result that NONE conforms to every
    type, expanded or not, formal generic or not.

Consequences:

1)  Will make generic classes less robust - it may even have
    the consequence that you cannot express certain things
    correctly (see example above).

2)  Will solve the problem at the cost of introducing a
    special rule for equality testing. Currently it is
    only necessary that the type of one of the operands
    conform to the type of the other. This rule is simple
    and elegant.

3)  Will solve the problem by removing a few words from
    a validity rule (VNCC-3). On the other hand, this
    would have the consequence that assignments of the
    form
            e := Void

    where 'e' is of expanded type will then also be valid.
    This, however, is not useful. But I think it's harm-
    less, since one can already write

            r := Void
            e := r

    if 'r' is of type T and 'e' of type expanded T. The
    result of executing this is the exception
    "Void_assigned_to_expanded". Furthermore, if the
    compiler detects an explicit assignment of the
    form
            e := Void

    and 'e' is known to be expanded (in particular: of
    basic type) the compiler can flag this as a bug, since
    it will never execute without raising an exception.

Personally, I prefer 3).
-----------------------------------------------------------
Best regards,
    Michael



From bertrand@vienna.eiffel.com Tue Apr  5 19:39:28 1994
Date: Tue, 5 Apr 94 19:39:25 PDT
To: bertrand@eiffel.com, switzer@namu01.gwdg.de
Subject: Re: MS-VNCC-3
Cc: tynor@atlanta.twr.com, eiffelgroup@vienna.eiffel.com
Content-Length: 153
X-Lines: 7
Status: RO

-----------------------------------------------
Agreeement (Bertrand Meyer)

Thanks for raising this point. I think solution 3 is the
proper one.

-- BM

From switzer@namu01.gwdg.de Sat Apr 16 06:43:00 1994
Date: Sat, 16 Apr 94 15:09:47 +0200
To: bertrand@eiffel.com
Subject: MS-VNCC-3 Addendum
Cc: tynor@atlanta.twr.com
Content-Length: 742
X-Lines: 22
Status: RO

-----------------------------------------------------------
Key   : MS-VNCC-3 Addendum
Title : One more consequence of 'NONE conforms to every type'.
-----------------------------------------------------------

I have noticed that the proposed change will have one more con-
sequence:

If NONE conforms to every type then an assignment of the form

        e := Void

where 'e' is of formal generic type 'G' is legal. However, it
would be appropriate to include a comment in ETL which says
that it is not wise to use such an assignment, because, if
executed, it will lead to a runtime error in case the
actual generic substituted for 'G' is expanded.
-----------------------------------------------------------

Best regards,
    Michael