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

NICE Language Committee: st-synonyms

-----------------------------------------------------------
Key   : ST-SYNONYMS
Title : Clarification of the notion of synonym
-----------------------------------------------------------
Clarification (Bertrand Meyer)

ETL states explicitly that synonym declarations are
equivalent to duplicate declarations. I think this is indeed
the semantics that is appropriate in practical cases.

So it is indeed correct that a should call a and b should call
b in the example.

I agree that the term "synonym" may be misunderstood but
can't think of a better one for the moment. I see this
as a problem of expression and will look for a better
way to describe and explain the notion. But as for the
actual semantics there is no doubt (in my mind
at least) that the correct interpretation
is the one that works as if the declarations had been
duplicated.

-----------------------------------------------------------
Discussion (Steve Tynor)

ETL is not clear (or not clear enough, for me!) on what the following
means:

	a, b is
	   external "C"
	   end;

[Note: there is no explicit `alias' clause.]  Specifically, do `a' and
`b' both call the same external function, "a" or do they each call a
different one ("a" and "b" respectively)?

The multiple declaration rule in section 5.16 says that this is
equivalent to:

	a is
	   external "C"
	   end;
	b is
	   external "C"
	   end;

which would imply that `a' calls "a" and `b' calls "b".

However, the section is liberally scattered with the term `synonym'
which would imply that `a' and `b' ought to do the same thing (hence
both `a' and `b' should both call the same external ("a"?)). On
reflection, however, even when talking about non-external features,
synonym is an inaccurate term. For attributes:

	c, d : INTEGER;

`c' and `d' are _not_ synonyms: they introduce two separate attributes.
[On the other hand, as I reread section 5.16, I think I could construct
an argument that it requires `c' and `d' to indeed refer to the same
attribute and be synonyms, despite the fact that this is inconsistent
with the semantics of entity_declarations for formal arguments and
locals.].

The current Tower implementation was (probably incorrectly) influenced
by the synonym-interpretation and causes `a' and `b' to both call
"a". We've had reports from customers that the ISE compiler calls "a"
and "b". I've not had a chance to test Eiffel/S. What do we as a group
think is correct?  I'm leaning to the ISE interpretation due to
orthogonality w/ attribute semantics (or at least
entity_declaration-consistent attribute semantics).

If we all agree, I think the use of the term `synonyms' is misleading
and ought to be stricken from the next version of ETL.
From Michael Schweitzer
Date: Tue, 5 Apr 94 14:28:48 +0200
To: bertrand@eiffel.com
Subject: ST-SYNONYMS
Cc: tynor@atlanta.twr.com
Content-Length: 1201
Status: RO
X-Lines: 48

To      : Bertrand Meyer, Steve Tynor
>From    : Michael Schweitzer
Subject : VIP-ST-SYNONYMS

-----------------------------------------------------------
Key   : ST-SYNONYMS
Title : Question on the notion of synonym features
-----------------------------------------------------------

I agree with Bertrand that a declaration of the form

        f1, f2, ..., fn is
            external Language_name
            end

is completetly equivalent to it's `unfolded' form

        f1 is
            external Language_name
            end

        ...

        fn is
            external Language_name
            end

that is, f1 uses external routine "f1", f2 uses "f2", etc.

However, in the language reference this should perhaps
be explained in more detail, especially since the declaration

        f1, f2, ..., fn is
            external Language_name
            alias    Alias_name
            end

has the effect that f1, f2, ..., fn will all call the
same external routine `Alias_name'.

I always interpreted it this way, but it would be better
for users if it were explained in more detail in the
book.
-----------------------------------------------------------

Best regards,
    Michael