NICE Language Committee: st-vzaa
From tynor@atlanta.twr.com Sun May 1 13:32:22 1994
Date: Sun, 1 May 94 13:53:26 EDT
To: langmey@eiffel.com, ms@ms.central.de (Michael Schweitzer)
Subject: VIP: ST-VZAA
Content-Length: 1511
Status: RO
X-Lines: 37
-----------------------------------------------------------
Key : ST-VZAA
Title: Address expression should allow formals, locals and Current
-----------------------------------------------------------
Proposal:
The current semantic rules relating to the operand of the address
operator restrict the operand to be an attribute or routine of the
enclosing class. This prevents passing the address of `Current',
`Result', local variables and routine arguments.
The Tower compiler allows all of these, as does I believe, the ISE
compiler (I'm afraid I've not tested Eiffel/S in this regard). I propose
that VZAA be relaxed:
VZAA: An Address expression `$f' is valid if and only if `f' is
a non-constant feature of the enclosing class, `Current', or a
formal argument or local entity of the enclosing routine.
[Note: the definition of "local entity" on page 115 specifically
includes `Result'].
This relaxation does not weaken the enforcement of encapsulation which I
suspect was the intent behind restricting the operands to features of
the enclosing class (one still cannot pass the address of a remote
class's feature).
Note to Bertrand: VZAA does not appear in the Index of the
pre-publication version of ETL/2 - I don't have a published copy handy
to check whether the published version added this.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Eiffel: Accept no substitutes.
Steve Tynor Internet: Steve.Tynor@atlanta.twr.com
Tower Technology UUCP: twratl!Steve.Tynor
From pertron.central.de!ms.central.de!ms@uranus.central.de Mon May 2 09:51:55 1994
Date: 02 May 1994 10:39:00 +0200
To: langmey@eiffel.com
Cc: tynor@atlanta.twr.com
Subject: ST-VZAA
X-Mailer: XP v3.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Content-Length: 985
Status: RO
X-Lines: 26
Dear Bertrand, dear Steve,
Disagreement
1) What will it be good for? I can't see any reason why one would
like to take the address of a local entity, an argument or
Current. I suspect that it's one of those 'convenience' features
that make up the better part of those computer languages which
we would definitely not like to work with.
2) Technical reason:
At least in our implementation, local entities, arguments and
Current, live on the machine stack (we don't maintain our own
stack). Therefore the address of such an entity becomes meaning-
less as soon as the enclosing routine terminates (returns).
Using a pointer to a local _after_ termination of the current
invocation of the routine will almost certainly crash the
system. Of course, there are many ways to crash a system, but
we should not add features which make this more likely,
especially if their usefulness is questionable.
Best regards,
Michael
## CrossPoint v3.0 ##
From tynor@atlanta.twr.com Mon May 2 11:00:04 1994
Date: Mon, 2 May 94 13:24:00 EDT
To: ms@ms.central.de (Michael Schweitzer)
Subject: re: ST-VZAA
References: <5O40GkfppmB@ms.central.de>
Cc: langmey@eiffel.com
Content-Length: 1692
Status: RO
X-Lines: 37
Michael writes:
| Disagreement
|
| 1) What will it be good for? I can't see any reason why one would
| like to take the address of a local entity, an argument or
| Current. I suspect that it's one of those 'convenience' features
| that make up the better part of those computer languages which
| we would definitely not like to work with.
For the same reason that one might need to pass the address of an
attribute out to C in order to do something interesting, one might need
to pass the address of a local value. It would be a shame (and
horrendously innefficient) to require assigning to a object variable and
passing that address (such a variable would likely have no other purpose
but to be a target of an Address operator!).
| 2) Technical reason:
|
| At least in our implementation, local entities, arguments and
| Current, live on the machine stack (we don't maintain our own
| stack). Therefore the address of such an entity becomes meaning-
| less as soon as the enclosing routine terminates (returns).
| Using a pointer to a local _after_ termination of the current
| invocation of the routine will almost certainly crash the
| system. Of course, there are many ways to crash a system, but
| we should not add features which make this more likely,
| especially if their usefulness is questionable.
This is true of our implementation too. Whenever one calls out of
Eiffel, once gives up a certain amount of safety.
Eiffel will succeed in large part depending on how well it allows the
programmer to interface with existing software. As distasteful as this
may seem, that may sometimes require passing the address of a local.
Steve
|
