Different generic derivations of the same class.

81 views
Skip to first unread message

Rosivaldo Fernandes Alves

unread,
Jan 18, 2017, 12:14:27 PM1/18/17
to Eiffel Users
Hi there.

Despite ECMA-367, section 8.6.13(5), the classes below compile with no complaint.
Notice that RELATION_FAMILY [A, B] is at the same time an (implicit) ST_SET [ST_SET [PAIR [A, B]]] and an (explicit) ST_SET [RELATION [A, B]].

However, if one uncomment the inherit clause of BROKEN_RELATION_FAMILY [A, B], such (explicit) repeated inheritance with different generic derivations of the same class causes the (expected) error "ECMA-VHPR(5): Different generic derivations of the same class are used in Parent parts."

Is it a bug in the compiler that allows the first case? I must add that some more complex scenarios of such implicit RI leads ES to crash instead of reporting an ECMA-VHPR(5) error.

Thanks for any clue.

Rosivaldo.

deferred class
    ST_SET [A]

feature

    with (x: A): ST_SET [A]
        deferred
        end

    without (x: A): ST_SET [A]
        deferred
        end

end

deferred class
    SET_FAMILY [A]

inherit
    ST_SET [ST_SET [A]]

feature

    with (x: ST_SET [A]): SET_FAMILY [A]
        deferred
        end

    without (x: ST_SET [A]): SET_FAMILY [A]
        deferred
        end

end

deferred class
    PAIR [A, B]

end

deferred class
    RELATION [A, B]

inherit
    ST_SET [PAIR [A, B]]

feature

    with (x: PAIR [A, B]): RELATION [A, B]
        deferred
        end

    without (x: PAIR [A, B]): RELATION [A, B]
        deferred
        end

end

deferred class
    RELATION_FAMILY [A, B]

inherit
    SET_FAMILY [PAIR [A, B]]
        rename
            with as sf_with
        select
            sf_with,
            without
        end

    ST_SET [RELATION [A, B]]
        rename
            without as ss_without
        end

feature

    sf_with (x: ST_SET [PAIR [A, B]]): RELATION_FAMILY [A, B]
        deferred
        end

    with (x: RELATION [A, B]): RELATION_FAMILY [A, B]
        deferred
        end

    without (x: ST_SET [PAIR [A, B]]): RELATION_FAMILY [A, B]
        deferred
        end

    ss_without (x: RELATION [A, B]): RELATION_FAMILY [A, B]
        deferred
        end

end

deferred class
    BROKEN_RELATION_FAMILY [A, B]

--inherit
--    ST_SET [RELATION [A, B]]

--    ST_SET [ST_SET [PAIR [A, B]]]

end

Rosivaldo Fernandes Alves

unread,
Jan 18, 2017, 12:34:20 PM1/18/17
to Eiffel Users
By the way, RELATION_FAMILY [A, B]  could the simpler (though more vulnerable to CATCALLs):


deferred class
    RELATION_FAMILY [A, B]

inherit
    SET_FAMILY [PAIR [A, B]]

    ST_SET [RELATION [A, B]]

feature

    with (x: RELATION [A, B]): RELATION_FAMILY [A, B]
        deferred
        end

    without (x: RELATION [A, B]): RELATION_FAMILY [A, B]
        deferred
        end

end


Rosivaldo Fernandes Alves

unread,
Feb 15, 2017, 7:11:43 PM2/15/17
to Eiffel Users
Does someone know how to clarify the matter below? Maybe it was not stated clearly...


Em quarta-feira, 18 de janeiro de 2017 14:14:27 UTC-3, Rosivaldo Fernandes Alves escreveu:

Alexander Kogtenkov

unread,
Feb 16, 2017, 4:52:34 AM2/16/17
to eiffel...@googlegroups.com
At the moment EiffelStudio checks the rule only for parents of a class, not for all its ancestors. This explains why an error is not reported in one case and is reported in another.

As to the case with a crash - do you have a reproducible example?

Regards,
Alexander Kogtenkov


Четверг, 16 февраля 2017, 3:11 +03:00 от Rosivaldo Fernandes Alves <rosivaldo.fe...@gmail.com>:

Rosivaldo Fernandes Alves

unread,
Feb 17, 2017, 5:56:36 AM2/17/17
to eiffel...@googlegroups.com
Thanks, Alexander. It is clear now.

About the crash: I don't know exactly how to reproduce it. Sorry. I was
working with some rather complicated (to my little experience) class
hierarchies. I gave up when confirmed the existence of the ECMA-VHPR(5)
error and didn't keep the old, broken code.

I insisted in the question far after my problems because I'd like to
know whether it was planned to relax ECMA in order to accept cases like
the one I've just exposed (as ES "accepts"). If I could vote, I'd vote
for relaxing. Inheriting SET [INTEGER] and SET [STRING] at once may be
senseless, but inheriting SET [COMPARABLE] and SET [STRING] (as a
refinement), seems sensible to me, since STRING conforms to COMPARABLE.
Is there any discussion in ECMA/Eiffel community about that?

Again, thanks for all.

Rosivaldo.

Em 16/02/2017 06:52, 'Alexander Kogtenkov' via Eiffel Users escreveu:
> At the moment EiffelStudio checks the rule only for parents of a class,
> not for all its ancestors. This explains why an error is not reported in
> one case and is reported in another.
>
> As to the case with a crash - do you have a reproducible example?
>
> Regards,
> Alexander Kogtenkov
>
>
> (...)

Emmanuel Stapf

unread,
Feb 17, 2017, 1:06:54 PM2/17/17
to eiffel...@googlegroups.com

Hi,

Allowing SET [COMPARABLE] in an ancestor and then SET [STRING] in a descendant would not be good since it would allow you to insert something that conforms to COMPARABLE but not to STRING in something that is supposed to be a SET [STRING]. A typical catcall error. The experimental catcall checker would disallow this by default. To enable it you would have to declare the type differently to forbid any formal generic parameters as argument, meaning that you can never insert in the SET which I think would defy what you are trying to achieve.

Hope this helps,
Manu
> --
> You received this message because you are subscribed to the Google
> Groups "Eiffel Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to eiffel-users...@googlegroups.com.
> Visit this group at https://groups.google.com/group/eiffel-users.
> For more options, visit https://groups.google.com/d/optout.

Alexander Kogtenkov

unread,
Feb 17, 2017, 1:17:44 PM2/17/17
to eiffel...@googlegroups.com
It looks like there is an issue if the rule is relaxed. Indeed, in the example with SET [STRING] and SET [COMPARABLE] there is some intermediate ancestor X that inherits SET [COMPARABLE]. Therefore, it is possible to assign current type that conforms to SET [STRING] to a variable of type X:

   x: X -- X inherits SET [COMPARABLE]
   ...
   x := set_of_strings -- a type of set_of_strings inherits X and SET [STRING]

Now it becomes possible to insert values other than strings into x:

   x.put (2017)

Then, set_of_strings will have an integer inside it and this is wrong. So, there are little chances that the rule can be relaxed. It might be possible to do that, but features with covariant arguments could not be called in that case.

Regards,
Alexander Kogtenkov


Пятница, 17 февраля 2017, 13:56 +03:00 от Rosivaldo Fernandes Alves <rosivaldo.fe...@gmail.com>:

Rosivaldo Fernandes Alves

unread,
Feb 19, 2017, 6:50:08 PM2/19/17
to eiffel...@googlegroups.com
Hi Manu and Alexander.

I had seen the catcall problem threatening my approach. But this risk
already exists. By default.

local
cs: SET [COMPARABLE]
ss: SET [STRING]
do
create ss -- etc.
cs := ss -- SET [STRING] conforms(!) to SET [COMPARABLE]
cs.put (123) -- CATCALL!!!
...

Please have a look at my sample code in the original post of this
thread: I have taken care, by renaming and selecting, in order to
mitigate the risk of catcall. I said "mitigate" because in the current
state of Eiffel I simply don't know how to prevent it altogether.

My point is another. Let me try a simpler (I hope) example.

class ORDERED_PAIR [A, B]

feature
a: A
b: B
end

class BINARY_RELATION [A, B]

inherit
MY_SET [ORDERED_PAIR [A, B]]
end

class HOMOGENEOUS_PAIR [A]

inherit
ORDERED_PAIR [A, A]

feature
is_identical: BOOLEAN
-- Are `a' and `b' equal?
end

class ENDORELATION [A]

inherit
BINARY_RELATION [A, A]
MY_SET [HOMOGENEOUS_PAIR [A]]
end

The code above is, obviously, only a sketch. Consider the class
ENDORELATION [A]. It is a kind of BINARY_RELATION [A, A], i.e. a MY_SET
[ORDERED_PAIR [A, A]]. There are several scenarios where ENDORELATION
[A] *should* be seen as a MY_SET [HOMOGENEOUS_PAIR [A]]. For instance,
{HOMOGENEOUS_PAIR [A]}.`is_identical' is a query that would not fit
naturally in ORDERED_PAIR [A, B]. And is not available in ORDERED_PAIR
[A, A], despite the generic parameters of same type. But it is a kind of
query that an ENDORELATION [A] certainly needs to ask to its pairs.
Sure, I can write an {ENDORELATION [A]}.pair_is_identical (p:
ORDERED_PAIR [A, A]): BOOLEAN feature. And, yes, I have done that or
whatever I need to workaround the fact that my ENDORELATION can't be at
the same time a BINARY_RELATION and a set of HOMOGENEOUS_PAIR as is
taxonomically natural.

What if my ENDORELATION [A] object is attached to a MY_SET [ORDERED_PAIR
[A, A]] entity and the latter tries to put an ORDERED_PAIR [A, A]
instead of an HOMOGENEOUS_PAIR [A] into may endorelation? As I've said,
by renaming and selecting, I managed to deal with such a case, easily
converting an ORDERED_PAIR [A, A] into an HOMOGENEOUS_PAIR [A] before
putting it into my endorelation.

In time: the above inherit clause of ENDORELATION compiles, though, as
you clarified, it should not (according to ECMA-367). In my unpretending
opinion, it should.

As to the catcall problem... It is sad. Eiffel is 32 years old. Time to
get rid of catcalls once and for all.

Once more, thanks for your attention.

Rosivaldo.

PS: In 1985 two amazing things were born: the Time DeLorean and the
Eiffel language. I take a chance on saying that 2015 came and went away
without gracing us with some astonishing technological advances seen in
Back to the Future Part II because Eiffel was not healed of catcalls in
the early nineties. ;-)

PS 2: My English is not that good for so detailed texts. Please forgive
any fault of mine.

Em 17/02/2017 15:17, 'Alexander Kogtenkov' via Eiffel Users escreveu:
> It looks like there is an issue if the rule is relaxed. Indeed, in the
> example with SET [STRING] and SET [COMPARABLE] there is some
> intermediate ancestor X that inherits SET [COMPARABLE]. Therefore, it is
> possible to assign current type that conforms to SET [STRING] to a
> variable of type X:
>
> x: X -- X inherits SET [COMPARABLE]
> ...
> x := set_of_strings -- a type of set_of_strings inherits X and SET
> [STRING]
>
> Now it becomes possible to insert values other than strings into x:
>
> x.put (2017)
>
> Then, set_of_strings will have an integer inside it and this is wrong.
> So, there are little chances that the rule can be relaxed. It might be
> possible to do that, but features with covariant arguments could not be
> called in that case.
>
> Regards,
> Alexander Kogtenkov
>
>
> (...)

Alexander Kogtenkov

unread,
Feb 21, 2017, 3:07:16 AM2/21/17
to eiffel...@googlegroups.com
The example is clear, thank you.

There is a solution to the cat-call problem, but it does not come for free: a lot of existing code needs to be updated. Moreover, there are issues with agents that require review of agent types. Hopefully at some point the issues will be resolved, but it's a question if users will accept the changes in the first place.

Coming back to your example, would it help if VHPR-5 is properly reported? I guess, the code will not compile at all. Is it acceptable? If not, how is it possible to prevent inserting ORDERED_PAIR [A, A] into ENDORELATION [A] when this is done through an entity of type BINARY_RELATION [A, A] or MY_SET [ORDERED_PAIR [A, A]]? I believe the cat-call solution will not allow attaching an expression of type ENDORELATION [A] to this entity. Will it be satisfactory?

Basically, the cat-calls are caused by simultaneous use of covariant redeclarations and dynamic binding. So, the solution is to disallow both of them to happen at the same time. Given that for reuse it makes sense to allow ENDORELATION [A] to be a descendant of BINARY_RELATION [A, A] and of MY_SET [HOMOGENEOUS_PAIR [A]], i.e. to allow implicit covariant redeclaration of some features, either dynamic binding should be disabled or covariant features cannot be called.

As soon as this machinery is in place, it might be possible to relax VHPR-5. But I believe it should take inheritance into account. In your example different generic derivations come along the same inheritance path. Almost. I would say, the classes might need to be defined in a bit more general way:

    class GENERAL_BINARY_RELATION [A, B, P -> ORDERED_PAIR [A, B]] inherit
        MY_SET [P]

    end

    class BINARY_RELATION [A, B] inherit
        GENERAL_BINARY_RELATION [A, B, ORDERED_PAIR [A, B]]
    end

    class ENDORELATION [A] inherit
         GENERAL_BINARY_RELATION [A, A, HOMOGENEOUS_PAIR [A]]
    end

because otherwise it is not clear which inheritance path takes precedence when it uses BINARY_RELATION [A, A] and MY_SET [HOMOGENEOUS_PAIR [A]] at the same time - is it MY_SET [ORDERED_PAIR [A, A]] or MY_SET [HOMOGENEOUS_PAIR [A]]? With the declaration above there is no such an issue.

BTW, after this generalization, it looks like VHPR-5 is satisfied, so, maybe it is not that harmful after all.

Regards,
Alexander Kogtenkov


Rosivaldo Fernandes Alves <rosivaldo.fe...@gmail.com>:

Rosivaldo Fernandes Alves

unread,
Feb 22, 2017, 6:40:23 AM2/22/17
to eiffel...@googlegroups.com
Please see my comments inline...

Em 21/02/2017 05:07, 'Alexander Kogtenkov' via Eiffel Users escreveu:
> The example is clear, thank you.
>
> There is a solution to the cat-call problem, but it does not come for
> free: a lot of existing code needs to be updated. Moreover, there are
> issues with agents that require review of agent types. Hopefully at some
> point the issues will be resolved, but it's a question if users will
> accept the changes in the first place.

Those are good news.

> Coming back to your example, would it help if VHPR-5 is properly
> reported? I guess, the code will not compile at all. Is it acceptable?

Definitely yes! Too bad to get bad (compiler) news too late.

> If not, how is it possible to prevent inserting ORDERED_PAIR [A, A] into
> ENDORELATION [A] when this is done through an entity of type
> BINARY_RELATION [A, A] or MY_SET [ORDERED_PAIR [A, A]]? I believe the
> cat-call solution will not allow attaching an expression of type
> ENDORELATION [A] to this entity. Will it be satisfactory?

The community will say. To me, as I've said, I found a way to prevent
this catcall. But "my" way does not forbid a MY_SET [detachable separate
ANY] entity from trying to insert a BASIC_ROUTINES into my poor
ENDORELATION [A]. So "my" way is not really a solution. :-(

> Basically, the cat-calls are caused by simultaneous use of covariant
> redeclarations and dynamic binding. So, the solution is to disallow both
> of them to happen at the same time. Given that for reuse it makes sense
> to allow ENDORELATION [A] to be a descendant of BINARY_RELATION [A, A]
> and of MY_SET [HOMOGENEOUS_PAIR [A]], i.e. to allow implicit covariant
> redeclaration of some features, either dynamic binding should be
> disabled or covariant features cannot be called.

The difficult point is that covariant generic parameters make sense (in
general) for covariant query results, but open the doorways for catcalls
when covariant feature arguments gets in the game. Perhaps we need a way
to distinguish the pretended use of a generic parameter.

> As soon as this machinery is in place, it might be possible to relax
> VHPR-5. But I believe it should take inheritance into account. In your
> example different generic derivations come along the same inheritance
> path. Almost. I would say, the classes might need to be defined in a bit
> more general way:
>
> class GENERAL_BINARY_RELATION [A, B, P -> ORDERED_PAIR [A, B]] inherit
> MY_SET [P]
> end
>
> class BINARY_RELATION [A, B] inherit
> GENERAL_BINARY_RELATION [A, B, ORDERED_PAIR [A, B]]
> end
>
> class ENDORELATION [A] inherit
> GENERAL_BINARY_RELATION [A, A, HOMOGENEOUS_PAIR [A]]
> end
>
> because otherwise it is not clear which inheritance path takes
> precedence when it uses BINARY_RELATION [A, A] and MY_SET
> [HOMOGENEOUS_PAIR [A]] at the same time - is it MY_SET [ORDERED_PAIR [A,
> A]] or MY_SET [HOMOGENEOUS_PAIR [A]]? With the declaration above there
> is no such an issue.

At this point I must clarify that so far I had made such experiments at
the deferred class level only. I'm not sure how the compiler would
behave when applying those mechanisms on fully implemented classes. My
guesses have little value in the face of the wider scene.

By the way, I had experimented with the kind of generalization you
propose. It seems to work well, despite some minor issues. But the
VHPR-5 case made me to want to be sure about what was going on after
all: was ES failing on reporting this error when it was "hideen" by
indirect RI? Or did ES intend to relax VHPR-5 and should ECMA be updated
in the future to allow such relaxation?

> BTW, after this generalization, it looks like VHPR-5 is satisfied, so,
> maybe it is not that harmful after all.
>
> Regards,
> Alexander Kogtenkov

Thanks for your precious time, Alexander.

I hope, in the near future, to have some (tiny) contribution to the
Eiffel community. The help of you all has been very much appreciated.

Rosivaldo.

Alexander Kogtenkov

unread,
Feb 23, 2017, 11:17:44 AM2/23/17
to eiffel...@googlegroups.com
Rosivaldo Fernandes Alves <rosivaldo.fe...@gmail.com>:

> By the way, I had experimented with the kind of generalization you
> propose. It seems to work well, despite some minor issues.

If the issues are general, feel free to discuss them, please.

Regards,
Alexander Kogtenkov

Rosivaldo Fernandes Alves

unread,
Mar 4, 2017, 4:59:05 PM3/4/17
to eiffel...@googlegroups.com
Hi, Alexander.

The minor issues are:

- some of my objects got a type declaration overly verbose;
- making BINARY_RELATION [A, B] and ENDORELATION [A] descendants of
GENERAL_BINARY_RELATION [A, B, P -> ORDERED_PAIR [A, B]] mitigates this
verbosity with the cost making ENDORELATION [A] to loose its conformance
with BINARY_RELATION [A, A].

But, as I say, these issues are minor. I can survive them. :-)

Regards,

Rosivaldo.
Reply all
Reply to author
Forward
0 new messages