[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Liberty-eiffel] renaming of ARRAY comparison features
From: |
Raphael Mack |
Subject: |
Re: [Liberty-eiffel] renaming of ARRAY comparison features |
Date: |
Thu, 16 Jun 2016 21:44:22 +0200 |
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
>