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

[Raphael Mack]

I now read your bug report. Thanks. - This shows, that we have some
problem here and we should implement some detection mechanism for such
stack overflows.

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.

Regards,
Rapha

Am Donnerstag, den 16.06.2016, 21:44 +0200 schrieb Raphael Mack:
> Hi,
> 
> 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
> more.
> 
> Regards,
> Rapha
> 
> 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
> > 
> 
> 
>