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

[Laurie Moye]

Hi Rapha,

On 16/06/16 21:00, Raphael Mack wrote:
> 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.
I assume the seg fault is because the stack runs out of space. In the
example, that is because of runaway recursion and it could be detected
by the repetitive nature of the entries on the stack. In general,
though, I think it might be impossible to distinguish between very deep
legitimate recursion and runaway recursion. Some problem-solving
programs, for example, might appear to be doing endless recursion, but
will be counting the levels as a stopping critereon.

Probably the best that could be done would be to catch it before the
stack limit is reached and issue a nice message saying "you have run out
of stack".


> 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.
Well, that's a simple way of making my program work, and that's exactly
what I have done. But I think the swapping of the names is a mistake.
Because I hate having to keep editing code because the language changes,
I am loth to suggets reverting the names, but I think checking the
contents of a container with an is_equal that itself uses is_equal is
just plain wrong (see below).

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

Yes, is_equal_map was wierd, but the point about the comparison using
'=' is not that it is fast, it is that it conforms to the explanation
given in ETL about what all is_equal features are supposed to do. If you
have read ETL (or ECMA-367) you expect is_equal on a CONTAINER class to
compare the items in the comntainer with '='. It's as simple as that. It
you create circularly recursive structures, you know that you can rely
on it to be safe. You can't just rename it because it would be nice to
match the naming of other features.

>> > 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.
My point was not that using this will have slowed the compiler down, but
that the compiler never needed the old is_equal_map and, I suspect,
still has no need of the new is_equal.


>> > 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.
I hope now you have seen the example, you see that that is wrong.

>> > 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.
As you see, the example is compiled -no_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.

Is it now clear that the recursion is the expected behaviour of the
code, in the example, or do I need to explain this some more?

Best wishes,
             Laurie