[eiffel-users] Unfortunate consequences of {ARRAYED_LIST}.duplicate and `new_filled_list'

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[eiffel-users] Unfortunate consequences of {ARRAYED_LIST}.duplicate and `new_filled_list'

Finnian Reilly
Lured by the promise of a simplified agent syntax I thought I would have a go of migrating Eiffel-Loop to use the ECF configuration "1-15-0". I quickly realized that I had bitten off more than I could chew so for the time being I have reverted to "1-8-0" until I work out a strategy to do it incrementally. But I did get a preview of the kinds of problems I would encounter.

One of the problems is due to some unfortunate consequences of introducing the function `{ARRAYED_LIST}.duplicate'. With configuration "1-15-0" the compiler is insisting that I must have a creation routine `make (n: INTEGER)'. This is to satisfy the creation instruction in function `new_filled_list'. So now a special status has been given to this make routine, and one that will often run counter to the intentions of developers wishing to implement descendants. For example in this class EL_MATCH_ALL_IN_LIST_TP, it makes no sense in relation to the purpose of the class to have a (renamed) `make_list` creation routine. The three that are given are the only ones I wish to have.

An even more unfortunate consequnce of `duplicate' is that it is no longer possible to declare a deferred class that inherits ARRAYED_LIST unless you first undefine `new_filled_list', but now you are left with the bothersome task of having to implement this routine in all the implementations of the deferred class. An example of this kind of deferred class is EL_KEY_INDEXABLE_ARRAYED_LIST.

This kind of problem could have been avoided if instead `duplicate' had been implemented like this


   duplicate
(n: INTEGER): ARRAY [G]
         
-- Copy of sub-list beginning at current position
         
-- and having min (`n', `count' - `index' + 1) items.
     
local
         end_pos
: INTEGER
     
do
         
if after then
            create
Result.make_empty
         
else
            end_pos
:= count.min (index + n - 1)
            create
Result.make_filled (item, 1, end_pos - index + 1)
           
Result.area.copy_data (area_v2, index - 1, 0, end_pos - index + 1)
         
end
     
end


Voilà: no need for the troublesome `new_filled_list' routine, and it's no trouble to make a new arrayed list from an array. It could be made even easier with the addition of a conversion statement to ARRAYED_LIST.
convert
    make_from_array
({ARRAY [G]})

I hope Eiffel Software will consider changing it sometime in the future.  For the time being I plan to fork it in Eiffel-Loop.


--
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 [hidden email].
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

RE: [eiffel-users] Unfortunate consequences of {ARRAYED_LIST}.duplicate and `new_filled_list'

Emmanuel Stapf
Administrator

Dear Finnian,

 

I’m not sure why you are having the problem now, the feature `duplicate` has been around for a very long time (at least since 2004) and changing its signature would break more code. However, there is one change in the compiler that would cause the error to appear when using the latest settings, it is the fact that now the compiler enforces full class checking for all compilation. I cannot recall which version exactly, but the option to perform full class checking has been added a while back and you would have hit this issue too.

 

Although this is annoying, it is not detrimental, you just have to provide an implementation and in this case it is a simple one. If you look at the code of EiffelStudio you will see that we hit the same issue.

 

This issue was discussed in the past but no resolution has been taken to make non-valid code in a deferred class to compile as it is ok to have errors as long as with full class checking we check the inherited code to ensure it makes sense in descendants.

 

Thanks for the feedback,

Manu

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Finnian Reilly
Sent: Wednesday, May 17, 2017 08:26
To: Eiffel Users <[hidden email]>
Subject: [eiffel-users] Unfortunate consequences of {ARRAYED_LIST}.duplicate and `new_filled_list'

 

Lured by the promise of a simplified agent syntax I thought I would have a go of migrating Eiffel-Loop to use the ECF configuration "1-15-0". I quickly realized that I had bitten off more than I could chew so for the time being I have reverted to "1-8-0" until I work out a strategy to do it incrementally. But I did get a preview of the kinds of problems I would encounter.

One of the problems is due to some unfortunate consequences of introducing the function `{ARRAYED_LIST}.duplicate'. With configuration "1-15-0" the compiler is insisting that I must have a creation routine `make (n: INTEGER)'. This is to satisfy the creation instruction in function `new_filled_list'. So now a special status has been given to this make routine, and one that will often run counter to the intentions of developers wishing to implement descendants. For example in this class EL_MATCH_ALL_IN_LIST_TP, it makes no sense in relation to the purpose of the class to have a (renamed) `make_list` creation routine. The three that are given are the only ones I wish to have.

An even more unfortunate consequnce of `duplicate' is that it is no longer possible to declare a deferred class that inherits ARRAYED_LIST unless you first undefine `new_filled_list', but now you are left with the bothersome task of having to implement this routine in all the implementations of the deferred class. An example of this kind of deferred class is EL_KEY_INDEXABLE_ARRAYED_LIST.

This kind of problem could have been avoided if instead `duplicate' had been implemented like this


   duplicate
(n: INTEGER): ARRAY [G]
         
-- Copy of sub-list beginning at current position
         
-- and having min (`n', `count' - `index' + 1) items.
     
local
         end_pos
: INTEGER
     
do
         
if after then
            create
Result.make_empty
         
else
            end_pos
:= count.min (index + n - 1)
            create
Result.make_filled (item, 1, end_pos - index + 1)
           
Result.area.copy_data (area_v2, index - 1, 0, end_pos - index + 1)
         
end
     
end


Voilà: no need for the troublesome `new_filled_list' routine, and it's no trouble to make a new arrayed list from an array. It could be made even easier with the addition of a conversion statement to ARRAYED_LIST.

convert
    make_from_array
({ARRAY [G]})


I hope Eiffel Software will consider changing it sometime in the future.  For the time being I plan to fork it in Eiffel-Loop.

--
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 [hidden email].
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.

--
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 [hidden email].
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.
------------------------------------------------------------------------  
Eiffel Software
805-685-1006
http://www.eiffel.com       
Customer support: http://support.eiffel.com       
User group: http://groups.eiffel.com/join       
------------------------------------------------------------------------  
Reply | Threaded
Open this post in threaded view
|

Re: [eiffel-users] Unfortunate consequences of {ARRAYED_LIST}.duplicate and `new_filled_list'

Finnian Reilly
Hi Manu
thanks for your reply. I didn't realize duplicate was around for so long. Currently I am able to compile ARRAYED_LIST descendants without errors using ES 16.05 and the following system config
system:
   configuration_ns
= "1-8-0"
   name
= EL_base; uuid = "229b789e-09aa-11df-87c7-1bf8afd2bbad"
   library_target
= EL_base
   
   target
:
      name
= EL_base
     
      description
:
         
"""
            Library of reusable components for Eiffel. (http://www.eiffel-loop.com)
         """

      root
:
         all_classes
= true

      option
:
         
namespace = "Eiffel-Loop.Library"; trace = false; debug=false; warning=true; syntax = standard
         assertions
:
            precondition
= true; postcondition = true; check = true; invariant = false

`configuration_ns' BTW, is just a shorthand for the ECF schema attributes. I had assumed that the errors I was getting were a consequence of incrementing `configuration_ns' to "1-15-0". I seem to recall there is a `full_class_checking' option. Perhaps I can use this to suppress the errors if I switch to "1-15-0". That's good, because I was looking forward to the simplified agents.

regards
Finnian


On Wednesday, 17 May 2017 17:34:13 UTC+1, Emmanuel STAPF [ES] wrote:

Dear Finnian,

 

I’m not sure why you are having the problem now, the feature `duplicate` has been around for a very long time (at least since 2004) and changing its signature would break more code. However, there is one change in the compiler that would cause the error to appear when using the latest settings, it is the fact that now the compiler enforces full class checking for all compilation. I cannot recall which version exactly, but the option to perform full class checking has been added a while back and you would have hit this issue too.

 

Although this is annoying, it is not detrimental, you just have to provide an implementation and in this case it is a simple one. If you look at the code of EiffelStudio you will see that we hit the same issue.

 

This issue was discussed in the past but no resolution has been taken to make non-valid code in a deferred class to compile as it is ok to have errors as long as with full class checking we check the inherited code to ensure it makes sense in descendants.

 

Thanks for the feedback,

Manu

 

From: <a href="javascript:" target="_blank" gdf-obfuscated-mailto="v-uhSr1gAAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">eiffel...@... [mailto:<a href="javascript:" target="_blank" gdf-obfuscated-mailto="v-uhSr1gAAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">eiffel...@googlegroups.com] On Behalf Of Finnian Reilly
Sent: Wednesday, May 17, 2017 08:26
To: Eiffel Users <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="v-uhSr1gAAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">eiffel...@...>
Subject: [eiffel-users] Unfortunate consequences of {ARRAYED_LIST}.duplicate and `new_filled_list'

 

Lured by the promise of a simplified agent syntax I thought I would have a go of migrating Eiffel-Loop to use the ECF configuration "1-15-0". I quickly realized that I had bitten off more than I could chew so for the time being I have reverted to "1-8-0" until I work out a strategy to do it incrementally. But I did get a preview of the kinds of problems I would encounter.

One of the problems is due to some unfortunate consequences of introducing the function `{ARRAYED_LIST}.duplicate'. With configuration "1-15-0" the compiler is insisting that I must have a creation routine `make (n: INTEGER)'. This is to satisfy the creation instruction in function `new_filled_list'. So now a special status has been given to this make routine, and one that will often run counter to the intentions of developers wishing to implement descendants. For example in this class <a href="http://www.eiffel-loop.com/library/base/text/pattern-match/composite/el_match_all_in_list_tp.html" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.eiffel-loop.com%2Flibrary%2Fbase%2Ftext%2Fpattern-match%2Fcomposite%2Fel_match_all_in_list_tp.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHYobK7IZ-MSe_4DVJyb-xPF9jbgQ&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.eiffel-loop.com%2Flibrary%2Fbase%2Ftext%2Fpattern-match%2Fcomposite%2Fel_match_all_in_list_tp.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHYobK7IZ-MSe_4DVJyb-xPF9jbgQ&#39;;return true;">EL_MATCH_ALL_IN_LIST_TP, it makes no sense in relation to the purpose of the class to have a (renamed) `make_list` creation routine. The three that are given are the only ones I wish to have.

An even more unfortunate consequnce of `duplicate' is that it is no longer possible to declare a deferred class that inherits ARRAYED_LIST unless you first undefine `new_filled_list', but now you are left with the bothersome task of having to implement this routine in all the implementations of the deferred class. An example of this kind of deferred class is <a href="http://www.eiffel-loop.com/library/base/data_structure/list/el_key_indexable_arrayed_list.html" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.eiffel-loop.com%2Flibrary%2Fbase%2Fdata_structure%2Flist%2Fel_key_indexable_arrayed_list.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNErLB-MTbmCC4aWDxYj5rDAol3XSQ&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fwww.eiffel-loop.com%2Flibrary%2Fbase%2Fdata_structure%2Flist%2Fel_key_indexable_arrayed_list.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNErLB-MTbmCC4aWDxYj5rDAol3XSQ&#39;;return true;">EL_KEY_INDEXABLE_ARRAYED_LIST.

This kind of problem could have been avoided if instead `duplicate' had been implemented like this


   duplicate
(n: INTEGER): ARRAY [G]
         
-- Copy of sub-list beginning at current position
         
-- and having min (`n', `count' - `index' + 1) items.
     
local
         end_pos
: INTEGER
     
do
         
if after then
            create
Result.make_empty
         
else
            end_pos
:= count.min (index + n - 1)
            create
Result.make_filled (item, 1, end_pos - index + 1)
           
Result.area.copy_data (area_v2, index - 1, 0, end_pos - index + 1)
         
end
     
end


Voilà: no need for the troublesome `new_filled_list' routine, and it's no trouble to make a new arrayed list from an array. It could be made even easier with the addition of a conversion statement to ARRAYED_LIST.

convert
    make_from_array
({ARRAY [G]})


I hope Eiffel Software will consider changing it sometime in the future.  For the time being I plan to fork it in Eiffel-Loop.

--
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 <a href="javascript:" target="_blank" gdf-obfuscated-mailto="v-uhSr1gAAAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">eiffel-users...@googlegroups.com.
Visit this group at <a href="https://groups.google.com/group/eiffel-users" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/group/eiffel-users&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/group/eiffel-users&#39;;return true;">https://groups.google.com/group/eiffel-users.
For more options, visit <a href="https://groups.google.com/d/optout" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;" onclick="this.href=&#39;https://groups.google.com/d/optout&#39;;return true;">https://groups.google.com/d/optout.

--
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 [hidden email].
Visit this group at https://groups.google.com/group/eiffel-users.
For more options, visit https://groups.google.com/d/optout.