[comp.lang.eiffel] Rename/Redefine Table is Incorrect ?

ted@computing-maths.cardiff.ac.uk (Ted Lawson) (03/02/90)

	One entry in the rename/redefine table on page 155 of
	Eiffel: The Language (page 260 of OOSC) appears to be incorrect.

	Case 6 of the table claims that

		rename old as new
		redefine old, new

	causes b.old to bind to the same feature as c.new. However, on
	both our Vax and Sun implementations of Eiffel 2.2 I find that
	b.old binds to the same feature as c.old.

	Questions about the rationality of the semantics documented by
	this particular table entry have been raised here in the past
	[mmartin, 2431@isis.UUCP, Mar 89] ( - and answered
	[kain, 5434@corona.UUCP, Mar 89] ). Is the observed behaviour
	a fault, or has the mechanism been changed in version 2.2  so
	as to make the semantics easier to understand ?

Ted Lawson

ted@uk.ac.cf.cm
ted%cm.cf.ac.uk@nsfnet-relay.ac.uk

db@lfcs.ed.ac.uk (Dave Berry) (03/08/90)

In article <1190@cf-cm.UUCP> ted@computing-maths.cardiff.ac.uk (Ted Lawson) writes:
>	One entry in the rename/redefine table on page 155 of
>	Eiffel: The Language (page 260 of OOSC) appears to be incorrect.
>
>	Case 6 of the table claims that
>
>		rename old as new
>		redefine old, new
>
>	causes b.old to bind to the same feature as c.new.

In my recent artticle I assumed that this was the correct semantics.
Howver, I misread Case 4 of the table, for which I apologise.
I thought it read:

	f redefined theta'	theta	theta'	theta
	f renamed f'

The logic being that a1.f would be mapped to b1.f' by the renaming
and that the "redefinition" of f wouldn't affect this.

Now I'm just confused.  Cases 4 and 6 seem to contradict each other.

I apologise if I've confused anyone else.

 Dave Berry, LFCS, Edinburgh Uni.      db%lfcs.ed.ac.uk@nsfnet-relay.ac.uk

"The thought of someone sharing one's own preferences without also sharing
 one's aversions strikes most people as utterly inconceivable." - C. A. Tripp.

bertrand@eiffel.UUCP (Bertrand Meyer) (03/11/90)

In <2671@castle.ed.ac.uk>, db@lfcs.ed.ac.uk (Dave Berry) quotes
<1190@cf-cm.UUCP> by ted@computing-maths.cardiff.ac.uk (Ted Lawson) writes:
>>  One entry in the rename/redefine table on page 155 of
>>  Eiffel: The Language (page 260 of OOSC) appears to be incorrect.
>>
>>  Case 6 of the table claims that
>>
>>      rename old as new
>>      redefine old, new
>>
>>  causes b.old to bind to the same feature as c.new.

    Although Mr. Lawson's message itself did not make it to this
end of the world, I would like to state that Case 6 is correct
to all the extent of my knowledge. (It is apparently counter-intuitive
since this is not the first time it has been reported to me as being
incorrect.)

    When checking, however, I realized to my horror that our
current implementation does not agree with the table for Case 6.
This will be corrected shortly. Our apologies for this bug. 

-- Bertrand Meyer
bertrand@eiffel.com

ted@cf-cm.cm.cf.ac.uk (Ted Lawson) (03/13/90)

In article <266@eiffel.UUCP> bertrand@eiffel.UUCP (Bertrand Meyer) writes:
><1190@cf-cm.UUCP> by ted@computing-maths.cardiff.ac.uk (Ted Lawson) writes:
>>>  One entry in the rename/redefine table on page 155 of
>>>  Eiffel: The Language (page 260 of OOSC) appears to be incorrect.
>>>
>>>  Case 6 of the table claims that
>>>
>>>      rename old as new
>>>      redefine old, new
>>>
>>>  causes b.old to bind to the same feature as c.new.
>
> I would like to state that Case 6 is correct
>to all the extent of my knowledge. (It is apparently counter-intuitive
>since this is not the first time it has been reported to me as being
>incorrect.)
>
>    When checking, however, I realized to my horror that our
>current implementation does not agree with the table for Case 6.
>This will be corrected shortly. Our apologies for this bug. 
>
>-- Bertrand Meyer

	Not only is case 6 counter-intuitive (in relation to case 4)
	it also seems rather messy to implement (as your implementer
	has discovered !). Well, until now no one has reported the "bug"
	so why not leave the implementation alone and just correct the
	documentation at the next opportunity ( :-) /2).

	Alternatively, could you explain the reasoning behind case 6's
	behaviour as documented. The only defense that I've seen of this
	was Kai Ng's posting here in March '89 - and that wasn't so
	much a defense as a rather intricate calculus for determining
	what the true binding was in each case.

	Ted Lawson

	ted%cm.cf.ac.uk@nsfnet-relay.ac.uk
	ted@uk.ac.cf.cm