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

NICE Language Committee: 1-first-message

Date: Fri, 25 Mar 94 22:23:55 +0100
To: bertrand@eiffel.com
Subject: Convergence
Content-Length: 4458
Status: RO
X-Lines: 152

>From : Michael Schweitzer
To   : Bertrand Meyer

Dear Bertrand,

I would like to start the discussion with three topics. If you
feel that the form of the presentation is not appropriate,
please let me know.

Best regards,
    Michael

p.s.

Have you already informed Steve Tynor about our plan?
What do you think of calling this enterprise `VIP'
(Vendors Interoperability Program)?

-----------------------------------------------------------
Key   : MS-ADR
Title : Taking the address of a feature.
-----------------------------------------------------------

Discussion:

It is currently only permitted to take the address of a feature
as part of the list of actual arguments of a call. An assignment
of the form
            p := $feature_name,

where `p' is a local entity or an attribute of type POINTER
is not permitted. This is an exception to the otherwise general
rule that everything that can be used as an actual argument can
also be used as the right hand side of an assignment (and vice versa).

Proposal:

I propose that the construct 'Address' should no longer be part of
the construct 'Actual'. Instead it should become one of the alternatives
of construct 'Expression'. The syntax should be

            Address = "$" Feature_name

This is an expression of type POINTER. 'Feature_name' must be the
final name of a feature of the class which is not a constant
attribute.

Required changes:

Minimal changes in the syntax (which must be corrected anyway
since it currently reads '$Identifier' instead of '$Feature_name').
The semantics (p. 405) remain the same.

-----------------------------------------------------------
Key   : MS-POINTER
Title : Type POINTER - conformance.
-----------------------------------------------------------

Discussion:

As far as I can see, the conformance rules for type POINTER
are not clearly defined. I always thought that POINTER con-
forms only to itself and nothing but POINTER conforms to it.

But recently (comp.lang.eiffel - ISE bug report) Bertrand
said that POINTER should conform to ANY. If this is the
case then an assignment of the form

            a := p  -- `a' of type ANY, `p' of type POINTER

requires a type promotion, similar to the case

            a := i  -- `a' of type ANY, `i' of type INTEGER.

In the latter example `i' is first promoted to INTEGER_REF.

Proposals (two alternatives):

(1)

Type POINTER conforms only to itself and no type other than
POINTER conforms to it.

(2)

We introduce a class POINTER_REF. It has only one feature
`item' of type POINTER. POINTER is an expanded class which
inherits from POINTER_REF. POINTER conforms directly to
POINTER_REF (and therefore indirectly to ANY). In a reattachment
of the form

        r := p

where `r' is a reference type and `p' a POINTER, `p' is first
converted into a POINTER_REF and a reference to that object
is attached to r.

Comment:

I don't have a clear preference for one of the two proposals.
The only thing that matters for me is that there is a clear
and definite rule. Neither of the two proposals requires significant
changes in our new implementation. Currently we've implemented
version (2).

-----------------------------------------------------------
Key   : MS-EQ
Title : Semantics of `=' and `/='
-----------------------------------------------------------

Discussion:

In an equality expression of the form

            e = f   -- or e /= f

where `e' or `f' (or both) are of expanded type the result
is the same as the result of the expression

            equal (e, f)

(page 375).

On the other hand, in an instruction of the form

            e := f

where `e' or `f' are of expanded type the effect is that of
applying `standard_copy' or `standard_clone' (page 317).

I think that the comment on page 317 applies to equality
expressions as well - You can always explicitely use

            equal (e, f)

if you want to take advantage of redefinition.

Proposal:

I propose that `standard_equal' be used in equality expressions
if one of the operands is expanded.

Comment:

I think the language should treat the fundamental operations
of reattachment and equality testing in a consistent manner.
Either the semantics of both can be altered by the user or
none of them can be altered. Therefore I believe that we should
either use the triple (standard_copy, standard_clone, standard_equal)
or (copy, clone, equal). I prefer the former.
-----------------------------------------------------------