liberty-eiffel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Liberty-eiffel] renaming of ARRAY comparison features


From: Cyril ADRIAN
Subject: Re: [Liberty-eiffel] renaming of ARRAY comparison features
Date: Wed, 15 Jun 2016 23:03:13 +0200

That commit is five years old! I don't remember. Certainly something to do with naming consistency and what can be found in other languages.

I don't understand Laurie's problem. Of course there is "recursion". But it is not "treacherous". It must terminate, otherwise:
- Either you'd have to be able to handle objects of type ARRAY[ARRAY[ARRAY[ARRAY…]]]] (with … denoting infinity). You cannot write such a thing in Eiffel;
- Or you have an ARRAY[X] with X containing its ARRAY[X] container, i.e. with mutual references; in that case, it would be a bad design anyway to have each is_equal follow the reference to the other! It denotes a more general design problem. Note that out (or out_in_tagged_out_memory) will be quite problematic too :-)

I don't see any other explanation; please elaborate. (Example?)

Cheers,

Cyril

2016-06-15 9:29 GMT+02:00 Paolo Redaelli <address@hidden>:
Thank you for this bug report.

This change has been made with commit 08f1f3646e833f254070b9b4432e27876dcc7cd0 (see https://github.com/LibertyEiffel/Liberty/commit/08f1f3646e833f254070b9b4432e27876dcc7cd0 for details) and it was labelled that way:

"BIG SEMANTIC SHIFT: is_equal now uses the is_equal of its elements (old is_equal_map). The old behaviour (using basic = comparison) is available through fast_is_equal."

Beside the semantic change it should not have crashed your code.

May I ask you to give us a little test that triggers this bug? So we may add it to our test suite

Cyril, I quite don't remember the rationale behind this change. As it is as you wrote quite big, may you please sketch out the rationale of it?

Thanks to everyone

 Paolo


2016-06-14 19:30 GMT+02:00 Laurie Moye <address@hidden>:
I have recently got an old SmallEiffel/SmartEifel program to compile
with Liberty. It runs, but immediately crashes with a segmentation fault.

Investigation shows that this is due to a stack overflow caused by
infinite recursion of ARRAY.is_equal.

ARRAY has always had two comparison features. One compares every item in
the arrays with '='. I shall refer to this as the "safe" one as it is
incapable of causing recursion. The other compares the items in the
arrays with "is_equal". I shall refer to this as the "treacherous" one
as it can lead to recursion.

In SmallEiffel and SmartEiffel, the safe comparison feature was called
"is_equal". This conforms to the description of "is_equal" in both ETL
and ECMA-367.

The treacherous version was called "is_equal_map" in SmallEiffel and
SmartEiffel.

In Liberty Eiffel, the name "is_equal" has been taken and given to the
treacherous version. The safe version has been renamed "fast_is_equal".
 This is the reason my program crashed. When all occurrences of
"is_equal" are changed to "fast_is_equal" it runs happily.

Neiher SmallEiffel nor SmartEiffel seem to have ever used is_equal_map.
I have never found a use for it. Libery Eiffel does not seem to use
fast_is_equal.

I cannot see why the names would have been changed. Giving the name
"is_equal" to the treacherous version goes againt what I have always
thought the purpose of is_equal to be; namely a shallow comparison
feature in which any objects contained within the objects being tested
are required to be the same set of objects. I have never seen the point
of the treacherous version, If an array contains complex objects which
one wants to compare with something deeper than '=', it is most likely
that the precise details of the comparison will be depend upon the new
class being defined. An inhereted test itself using is_equal is unlikely
to meet any specific requirement, and is a dangerous thing to have
around. This point is made in the wiki:
http://wiki.liberty-eiffel.org/index.php/Comparison_of_objects
in connection with a TRIANGLE class:
"It is very hard to imagine how a good function for comparison could be
defined automatically. In particular, it is not always enough to call
is_equal again on the attribute".

I assume that there was a very good reason for changing the names, but I
can't find any documentation of it. Is there an explanation of it?
Does the compiler now need to use the treacherous version?

Is giving the name "is_equal" to the treacherous version the right thing
to have done?

Best wishes,
             Laurie







--
Cyril ADRIAN

reply via email to

[Prev in Thread] Current Thread [Next in Thread]