[Top][All Lists]

[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


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

reply via email to

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