Signature of ARRAYED_TREE.replace_child

[Eric Bezault]

Hello,

Can someone tell me why the signature of `replace_child' has
been changed from:

   replace_child (n: like parent)

to:

   replace_child (n: like new_cell)

This is causing flat Degree 3 errors in one of our classes
at AXA Rosenberg:

~~~~~~~~~~~~~~~~~
[VUAR-2] class ROSE_ARRAYED_TREE (ARRAYED_TREE,325,13): the 1-th actual
argument (of type '? ARRAYED_TREE [G]') does not conform to the
corresponding formal argument (of type 'ROSE_ARRAYED_TREE [G]') of
feature `replace_child' in class ROSE_ARRAYED_TREE.
---
[VUAR-2] class ROSE_ARRAYED_TREE (ARRAYED_TREE,373,13): the 1-th actual
argument (of type '? ARRAYED_TREE [G]') does not conform to the
corresponding formal argument (of type 'ROSE_ARRAYED_TREE [G]') of
feature `replace_child' in class ROSE_ARRAYED_TREE.
---
[VUAR-2] class ROSE_ARRAYED_TREE (ARRAYED_TREE,397,6): the 1-th actual
argument (of type '? ARRAYED_TREE [G]') does not conform to the
corresponding formal argument (of type 'ROSE_ARRAYED_TREE [G]') of
feature `replace_child'.
~~~~~~~~~~~~~~~~~

In our class ROSE_ARRAYED_TREE I tried to redefine `replace_child'
as follows:

~~~~~~~~~~~~~~~~~
        replace_child (n: like parent) is
                        -- Make `n' the node's current child.
                do
                        Precursor (n)
                end
~~~~~~~~~~~~~~~~~

As far as I know this is valid ECMA Eiffel, and this makes gelint
happy (no more flat Degree 3 errors). However EiffelStudio 6.2.7.3753
now complains with the following error:

~~~~~~~~~~~~~~~~~
Error code: VUAR(2)
Type error: non-conforming actual argument in feature call.
What to do: make sure that type of actual argument conforms to type
   of corresponding formal argument.

Class: ROSE_ARRAYED_TREE [G]
Feature: replace_child
Called feature: replace_child (n: [like new_cell] [like Current]
ROSE_ARRAYED_TREE [G]) from ARRAYED_TREE
Argument name: n
Argument position: 1
Actual argument type: ARRAYED_TREE [Generic #1]
Formal argument type: [like Current] ROSE_ARRAYED_TREE [Generic #1]
Line: 320
       do
->      Precursor (n)
       end
~~~~~~~~~~~~~~~~~

I could understand that the signature of `replace_child' be
changed to:

    replace_child (n: like child)

but I'm clueless as to why it is now:

   replace_child (n: like new_cell)

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Alexander Kogtenkov [ES]-2]

This was part of the modification towards void-safe code.
`parent' is of a detachable type and `new_cell' is of an attached one.
Probably, there is a better solution, but if we want default-attachment-status-agnostic
code, it's better to avoid using explicit ! attachment mark, that's why
"like new_cell" was used instead of "!like parent".

However, I'm not sure if `replace_child' expects non-void argument or not.
If Void is an accepted value, the signature can be safely reverted back.
If the value should not be Void, the issue needs more investigation.

Regards,
Alexander Kogtenkov


----- Original Message -----
From: "Eric Bezault" <[hidden email]>
To: "freeelks-devel" <[hidden email]>
Cc: "Emmanuel Stapf [ES]" <[hidden email]>; "Zoran Simic" <[hidden email]>
Sent: Monday, July 07, 2008 11:47 PM
Subject: [freeelks-devel] Signature of ARRAYED_TREE.replace_child

> Hello,
>
> Can someone tell me why the signature of `replace_child' has
> been changed from:
>
>    replace_child (n: like parent)
>
> to:
>
>    replace_child (n: like new_cell)
>
> This is causing flat Degree 3 errors in one of our classes
> at AXA Rosenberg:
>
> ~~~~~~~~~~~~~~~~~
> [VUAR-2] class ROSE_ARRAYED_TREE (ARRAYED_TREE,325,13): the 1-th actual
> argument (of type '? ARRAYED_TREE [G]') does not conform to the
> corresponding formal argument (of type 'ROSE_ARRAYED_TREE [G]') of
> feature `replace_child' in class ROSE_ARRAYED_TREE.
> ---
> [VUAR-2] class ROSE_ARRAYED_TREE (ARRAYED_TREE,373,13): the 1-th actual
> argument (of type '? ARRAYED_TREE [G]') does not conform to the
> corresponding formal argument (of type 'ROSE_ARRAYED_TREE [G]') of
> feature `replace_child' in class ROSE_ARRAYED_TREE.
> ---
> [VUAR-2] class ROSE_ARRAYED_TREE (ARRAYED_TREE,397,6): the 1-th actual
> argument (of type '? ARRAYED_TREE [G]') does not conform to the
> corresponding formal argument (of type 'ROSE_ARRAYED_TREE [G]') of
> feature `replace_child'.
> ~~~~~~~~~~~~~~~~~
>
> In our class ROSE_ARRAYED_TREE I tried to redefine `replace_child'
> as follows:
>
> ~~~~~~~~~~~~~~~~~
> replace_child (n: like parent) is
> -- Make `n' the node's current child.
> do
> Precursor (n)
> end
> ~~~~~~~~~~~~~~~~~
>
> As far as I know this is valid ECMA Eiffel, and this makes gelint
> happy (no more flat Degree 3 errors). However EiffelStudio 6.2.7.3753
> now complains with the following error:
>
> ~~~~~~~~~~~~~~~~~
> Error code: VUAR(2)
> Type error: non-conforming actual argument in feature call.
> What to do: make sure that type of actual argument conforms to type
>    of corresponding formal argument.
>
> Class: ROSE_ARRAYED_TREE [G]
> Feature: replace_child
> Called feature: replace_child (n: [like new_cell] [like Current]
> ROSE_ARRAYED_TREE [G]) from ARRAYED_TREE
> Argument name: n
> Argument position: 1
> Actual argument type: ARRAYED_TREE [Generic #1]
> Formal argument type: [like Current] ROSE_ARRAYED_TREE [Generic #1]
> Line: 320
>        do
> ->      Precursor (n)
>        end
> ~~~~~~~~~~~~~~~~~
>
> I could understand that the signature of `replace_child' be
> changed to:
>
>     replace_child (n: like child)
>
> but I'm clueless as to why it is now:
>
>    replace_child (n: like new_cell)
>
> --
> Eric Bezault
> mailto:[hidden email]
> http://www.gobosoft.com
>
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> freeelks-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/freeelks-devel

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Eric Bezault]

Alexander Kogtenkov wrote:
> This was part of the modification towards void-safe code.
> `parent' is of a detachable type and `new_cell' is of an attached one.
> Probably, there is a better solution, but if we want default-attachment-status-agnostic
> code, it's better to avoid using explicit ! attachment mark, that's why
> "like new_cell" was used instead of "!like parent".
>
> However, I'm not sure if `replace_child' expects non-void argument or not.
> If Void is an accepted value, the signature can be safely reverted back.
> If the value should not be Void, the issue needs more investigation.

In TREE the signature is:

    replace_child (n: like parent)

I think that if we change the signature just for the purpose of
void-safety, we should not change the semantics. `like parent'
means "?ARRAYED_TREE [G]". But `like new_cell' does not mean
"ARRAYED_TREE [G]". It means "like Current", which is different
when interpreted in descendant classes. If you don't want "!"
in the code, then instead of using `parent' as anchor, you
should use `child':

    child: ARRAYED_TREE [G] ....

    parent: ?like child

    replace_child (n: like child) ...

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Alexander Kogtenkov [ES]-2]

Eric Bezault wrote:

> In TREE the signature is:
>
>     replace_child (n: like parent)
>
> I think that if we change the signature just for the purpose of
> void-safety, we should not change the semantics. `like parent'
> means "?ARRAYED_TREE [G]". But `like new_cell' does not mean
> "ARRAYED_TREE [G]". It means "like Current", which is different
> when interpreted in descendant classes. If you don't want "!"
> in the code, then instead of using `parent' as anchor, you
> should use `child':
>
>     child: ARRAYED_TREE [G] ....
>
>     parent: ?like child
>
>     replace_child (n: like child) ...

Do you suggest to make these changes in the class TREE as well,
i.e. make `parent' anchored to `child'? I'm asking because it's not
clear to me whether `child' is always attached or not. In particular,
is it attached in BINARY_TREE and FIXED_TREE?

Thanks,
Alexander Kogtenkov

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel

[Eric Bezault]

Alexander Kogtenkov wrote:

> Eric Bezault wrote:
>
>> In TREE the signature is:
>>
>>     replace_child (n: like parent)
>>
>> I think that if we change the signature just for the purpose of
>> void-safety, we should not change the semantics. `like parent'
>> means "?ARRAYED_TREE [G]". But `like new_cell' does not mean
>> "ARRAYED_TREE [G]". It means "like Current", which is different
>> when interpreted in descendant classes. If you don't want "!"
>> in the code, then instead of using `parent' as anchor, you
>> should use `child':
>>
>>     child: ARRAYED_TREE [G] ....
>>
>>     parent: ?like child
>>
>>     replace_child (n: like child) ...
>
> Do you suggest to make these changes in the class TREE as well,
> i.e. make `parent' anchored to `child'? I'm asking because it's not
> clear to me whether `child' is always attached or not.

Indeed, `child' might not always be attached. Perhaps we
should introduce a new query just for the purpose of
having an anchor of attached type:

    find_a_good_name: ARRAYED_TREE [G]
        do
        end

    child: ?like find_a_good_name ...

    parent: ?like find_a_good_name

    replace_child (n: like find_a_good_name) ...

Perhaps this `find_a_good_name' query should be `new_cell',
but the problem with `new_cell' is that it returns a
'like Current' instead of an ARRAYED_TREE [G].

This comes to the question, should ARRAYED_TREE (and other
trees) be allowed to be heterogenous? In other words, is
it on purpose that `parent' and `child' were not of type
`like Current' so far but instead of type ARRAYED_TREE?
Should the trees be homogenous and should we change all
anchored types (and other signatures using explicitly
ARRAYED_TREE) to be 'like Current'? I'm not sure about
the possible consequences on the users' code.

Another thing that comes to my mind. Forgive me if this
has already been discussed as part of ECMA, I'm not a
big fan of attached types and void-safety (at least as
specified in ECMA) so I don't thoroughly follow all the
discussions on this topic. Why shouldn't 'like anchor'
always be considered as attached, regardless of whether
`anchor' is attached or not? I'm not sure whether this
might bring more confusion than good, or if it will
result in forcing people to write '?like anchor' with
the question mark more often than bearable.

--
Eric Bezault
mailto:[hidden email]
http://www.gobosoft.com

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
freeelks-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/freeelks-devel