[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Liberty-eiffel] renaming of ARRAY comparison features
Re: [Liberty-eiffel] renaming of ARRAY comparison features
Thu, 16 Jun 2016 22:00:13 +0200
I now read your bug report. Thanks. - This shows, that we have some
problem here and we should implement some detection mechanism for such
Nevertheless, I would like to keep the behavior of is_equal for
COLLECTIONS and think that the switch to fast_is_equal in your
application is the best option.
Am Donnerstag, den 16.06.2016, 21:44 +0200 schrieb Raphael Mack:
> I think the names as they are now, are more consistent with e. g.
> has/fast_has, replace_all/fast_replace_all, occurrences/fast_occurrences
> etc. And to be honest: what has "comparing collections on the basis of
> its content objects contents" to do with maps -> I didn't like to old
> name either.
> What I fully agree with, is that this change should have been documented
> the release notes for Adler (which I just added).
> For the compiler itself I think you are right, that we could change some
> of the is_equal usages by fast_is_equal, but I expect we do not compare
> too many containers anyhow.
> About the observation in your application to get some segmentation fault
> I don't believe that it directly comes from the change in is_equal.
> Either you have a problem in some is_equal implementation in your
> application or you see a different effect, which is only visible if
> is_equal is used and hidden with fast_is_equal. On the other side, an
> Eiffel program should NEVER terminate with a segfault, so I think your
> application shows a different bug in our compiler or GC.
> Have you already tried with different assertion levels and different GC
> or without GC at all? - I think that could help us to understand a bit
> Am Mittwoch, den 15.06.2016, 23:03 +0200 schrieb Cyril ADRIAN:
> > 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