liberty-eiffel
[Top][All Lists]
Advanced

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

[Liberty-eiffel] renaming of ARRAY comparison features


From: Laurie Moye
Subject: [Liberty-eiffel] renaming of ARRAY comparison features
Date: Tue, 14 Jun 2016 18:30:30 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0

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





reply via email to

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