[Top][All Lists]

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

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

From: Paolo Redaelli
Subject: Re: [Liberty-eiffel] renaming of ARRAY comparison features
Date: Wed, 15 Jun 2016 09:29:45 +0200

Thank you for this bug report.

This change has been made with commit 08f1f3646e833f254070b9b4432e27876dcc7cd0 (see 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


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

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

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:
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,

reply via email to

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