Loading ...
Sorry, an error occurred while loading the content.

[eiffel-nice-library] Re: ARRAY: insert or not

Expand Messages
  • Frieder Monninger
    ... We agreed to stay rational :-) (just a small comment) As it is can be rather efficient to implement insert especially for an array of extended something
    Message 1 of 17 , Sep 1, 1999
    • 0 Attachment
      At 11:28 31.08.99 -0700, marcel.satchel wrote:

      >To force into ARRAY features that do not properly belong there
      >undermines the Eiffel method. An ARRAY is not a DYNAMIC_LIST.

      We agreed to stay rational :-) (just a small comment)

      As it is can be rather efficient to implement insert especially for
      an array of "extended" something in Runtime this feature will
      help that Eiffel will be more wildely used. (using for example
      a move from memory to memory)

      If it is not in the Runtime, it must be programmed "manually"
      in Eiffel with much ower performance.

      Maybe will undermine the method .. but we will support the
      Euffel usage.

      Btw, my opinion as member of OT is simple: We can have
      a standard without "insert" as it can be written in Eiffel source.
      Nevertheless OT will extend ELKS by providing this feature.
      I am sure, ISE and the Smalleiffel people will do the same.

      So, why not put it in the standard ?

      Manu, Dominique, whats your opinion ?

      --
      Frieder Monninger
      Object Tools GmbH

      fm@... --- http://www.object-tools.com
      Nordstr. 5 - D 35619 Braunfels - fon +49 6472 911 030 fax 031
    • dominique.colnet@loria.fr
      ... We couldn t have written it better :) Another example of dinausaur is ELKS 95, which we are now trying to evolve a bit :) Dominique Colnet & Olivier Zendra
      Message 2 of 17 , Sep 1, 1999
      • 0 Attachment
        Pierre Metras wrote:

        > EiffelBase is effectively a well crafted collection of data structures.But
        > its extensive taxonomy of data-structures reminds me of the alignments of
        > lepidopterous in museums. In my day to day life, I only want to call an
        > insect a
        > butterfly, even a Monarque, but rarely a "Danaus plexippus".
        > These same days, when I need to select a data-structure for my code, I
        > select an ARRAY if I need to access its items by indexes or a LIST if I need
        > to access the items by relative position. But I don't care to know the
        > internal differences between ARRAYED_LIST or LISTED_ARRAY. I expect an ARRAY
        > to fulfill all the operations I need: storage (put), retrieval (item),
        > reorganization (insert or add, resize and append), extraction (subarray)...
        > Natural
        > species selection promotes better features in upper classes, as would say
        > Darwin ;-)

        We couldn't have written it better :)

        Another example of dinausaur is ELKS 95, which we are now trying to
        evolve a bit :)


        Dominique Colnet & Olivier Zendra

        ELKS 2000 discussion: http://www.egroups.com/group/eiffel-nice-library
        ELKS 2000 web site: http://smalleiffel.loria.fr/elks2000
      • dominique.colnet@loria.fr
        ... Wrong. And this is not a very constructive approach. If everybody followed your reasoning, we would write that ELKS2000 should be extended to cover all of
        Message 3 of 17 , Sep 1, 1999
        • 0 Attachment
          Marcel Satchell wrote:

          > If you want standardised facility features then ask for ELKS to
          > be extended to cover all of EiffelBase. There is no other way to
          > achieve what you want.

          Wrong. And this is not a very constructive approach.

          If everybody followed your reasoning, we would write that ELKS2000
          should be extended to cover all of the (very well designed) SmallEiffel
          library. OT people would write the same about VisualEiffel. And so on...

          As Franck (ISE user) already explained to you quite clearly, this is not
          why ELKS was created and not what users want.

          Furthermore, this is not the approach Emmanuel Stapf (Manu) from ISE took
          when discussing the initial ELKS 2000 proposal with us in Nancy.


          Dominique Colnet & Olivier Zendra

          ELKS 2000 discussion: http://www.egroups.com/group/eiffel-nice-library
          ELKS 2000 web site: http://smalleiffel.loria.fr/elks2000
        • dominique.colnet@loria.fr
          ... We don t agree. Our Eiffel compiler, SmallEiffel is written in Eiffel, as are our libraries, with as little C as possible. Our add feature is
          Message 4 of 17 , Sep 1, 1999
          • 0 Attachment
            Frieder Monninger wrote:

            > As it is can be rather efficient to implement insert especially for
            > an array of "extended" something in Runtime this feature will
            > help that Eiffel will be more wildely used. (using for example
            > a move from memory to memory)
            >
            > If it is not in the Runtime, it must be programmed "manually"
            > in Eiffel with much ower performance.

            We don't agree. Our Eiffel compiler, SmallEiffel is written in
            Eiffel, as are our libraries, with as little C as possible.
            Our 'add' feature is _completely_ written in Eiffel and is very fast.
            Why should efficiently optimized Eiffel be slow ???

            > Maybe will undermine the method .. but we will support the
            > Euffel usage.
            >
            > Btw, my opinion as member of OT is simple: We can have
            > a standard without "insert" as it can be written in Eiffel source.
            > Nevertheless OT will extend ELKS by providing this feature.
            > I am sure, ISE and the Smalleiffel people will do the same.

            Indeed, 'add' is of course already there in SmallEiffel.

            > So, why not put it in the standard ?
            > Manu, Dominique, whats your opinion ?

            We (SmallEiffel people) agree.

            That is why 'add_*' routines are already present in the current ELKS 2000
            proposal:
            http://smalleiffel.loria.fr/elks2000/current_array.html

            Manu ?




            Dominique Colnet & Olivier Zendra

            ELKS 2000 discussion: http://www.egroups.com/group/eiffel-nice-library
            ELKS 2000 web site: http://smalleiffel.loria.fr/elks2000
          • marcel.satchell@eiffel.co.uk
            ... OK, performance advantage of runtime insert (and prune) noted. However, I m uneasy. Too far down this path and we should be considering an ARRAYED_LIST
            Message 5 of 17 , Sep 1, 1999
            • 0 Attachment
              >
              > Maybe will undermine the method .. but we will support the
              > Euffel usage.
              >

              OK, performance advantage of runtime insert (and prune)
              noted.

              However, I'm uneasy. Too far down this path and we should
              be considering an ARRAYED_LIST class, which puts us in
              a minefield it seems to me.

              -- Marcel
            • marcel.satchell@eiffel.co.uk
              marcel.satchel-@eiffel.co.uk wrote: original article:http://www.egroups.com/group/eiffel-nice-library/?star t=206 ... Attempting to force too much into ELKS
              Message 6 of 17 , Sep 1, 1999
              • 0 Attachment
                marcel.satchel-@... wrote:
                original article:http://www.egroups.com/group/eiffel-nice-library/?star
                t=206
                > Marcel Satchell wrote:
                >
                > > If you want standardised facility features then ask for ELKS to
                > > be extended to cover all of EiffelBase. There is no other way to
                > > achieve what you want.
                >
                > Wrong. And this is not a very constructive approach.
                >

                Attempting to force too much into ELKS will be self-defeating.
                Being `destructive' to be `constructive' if there is such a thing.

                > If everybody followed your reasoning, we would write that ELKS2000
                > should be extended to cover all of the (very well designed)
                SmallEiffel
                > library. OT people would write the same about VisualEiffel. And so
                on...
                >

                Not quite. ISE came first. EiffelBase is first among data structure
                libraries. The SmallEiffel libraries are not well written - not the
                last time I looked at them. They are a mess; the algorithmic integrity
                is irrelevant (and may well be excellent), but the class texts
                themselves,
                what I have seen of them and the compiler texts, are something to be
                ashamed of. Perhaps more recent versions are better. The VisualEiffel
                libraries are even worse.

                > As Franck (ISE user) already explained to you quite clearly, this is
                not
                > why ELKS was created and not what users want.

                I'm a user. I do not want to see ELKS in any way compromise EiffelBase.
                EiffelBase is more important, in my judgement, than ELKS.


                > Furthermore, this is not the approach Emmanuel Stapf (Manu) from ISE
                took
                > when discussing the initial ELKS 2000 proposal with us in Nancy.

                I am not Emmanuel. I speak for myself. I have a deep involvement in
                EiffelBase, but I do not speak for ISE. They seem not to be very
                interested
                in this debate ... I wonder why?


                -- Marcel
              • Alexander Kogtenkov
                ... Dominique Colnet & Olivier Zendra ... In fact the question was should we include insert in the ARRAY or not . It does not matter how it is implemented.
                Message 7 of 17 , Sep 6, 1999
                • 0 Attachment
                  Frieder Monninger wrote:

                  >> because memory move is not supported in Eiffel. (I speak about
                  >> the I386 here). It really can be done extremly fast - with in line
                  >> assembly

                  Dominique Colnet & Olivier Zendra

                  >We don't rely on assembly code, since we trust the C compiler
                  >to take care of these optimizations. We in fact write as much
                  >as we can in Eiffel, trusting the Eiffel compiler to generate
                  >good optimized C code.

                  In fact the question was "should we include 'insert' in the ARRAY
                  or not". It does not matter how it is implemented.

                  regards,
                  Alexander Kogtenkov
                  Object Tools, Moscow
                • Frieder Monninger
                  ... because memory move is not supported in Eiffel. (I speak about the I386 here). It really can be done extremly fast - with in line assembly Whats your real
                  Message 8 of 17 , Sep 8, 1999
                  • 0 Attachment
                    At 08:55 01.09.99 -0700, you wrote:
                    >Frieder Monninger wrote:
                    >
                    >> As it is can be rather efficient to implement insert especially for
                    >> an array of "extended" something in Runtime this feature will
                    >> help that Eiffel will be more wildely used. (using for example
                    >> a move from memory to memory)
                    >>
                    >> If it is not in the Runtime, it must be programmed "manually"
                    >> in Eiffel with much ower performance.
                    >
                    >We don't agree. Our Eiffel compiler, SmallEiffel is written in
                    >Eiffel, as are our libraries, with as little C as possible.
                    >Our 'add' feature is _completely_ written in Eiffel and is very fast.
                    >Why should efficiently optimized Eiffel be slow ???

                    because memory move is not supported in Eiffel. (I speak about
                    the I386 here). It really can be done extremly fast - with in line
                    assembly

                    Whats your real opinion :-) - not the "official" one ??

                    --
                    Frieder Monninger
                    Object Tools GmbH

                    fm@... --- http://www.object-tools.com
                    Nordstr. 5 - D 35619 Braunfels - fon +49 6472 911 030 fax 031
                  • dominique.colnet@loria.fr
                    ... So SmallEiffel is bad, Visual Eiffel worse, and ISE EiffelBase an example to follow... This would be laughable if it were not a serious matter. We re not
                    Message 9 of 17 , Sep 8, 1999
                    • 0 Attachment
                      Marcel Satchell wrote:

                      > Not quite. ISE came first. EiffelBase is first among data structure
                      > libraries. The SmallEiffel libraries are not well written - not the
                      > last time I looked at them. They are a mess; the algorithmic integrity
                      > is irrelevant (and may well be excellent), but the class texts
                      > themselves,
                      > what I have seen of them and the compiler texts, are something to be
                      > ashamed of. Perhaps more recent versions are better. The VisualEiffel
                      > libraries are even worse.

                      So SmallEiffel is bad, Visual Eiffel worse, and ISE EiffelBase an
                      example to follow... This would be laughable if it were not a serious
                      matter.
                      We're not going to follow on your flame war, which belongs to alt.flame.
                      Anyone who has looked to the various Eiffel implementation and libraries,
                      and to the development of Eiffel since 1986 knows better than that.

                      > I'm a user. I do not want to see ELKS in any way compromise EiffelBase.
                      > EiffelBase is more important, in my judgement, than ELKS.

                      This is quite understandable, knowing that until recently you couldn't
                      tell us whether you were speaking for ISE or not (see below).

                      > I am not Emmanuel. I speak for myself.

                      Ok, that's good to know.

                      > I have a deep involvement in EiffelBase,

                      That indeed explains things a bit.

                      > but I do not speak for ISE. They seem not to be very
                      > interested in this debate ... I wonder why?

                      Indeed, why ? We'd love to have an official (not private e-mail) position
                      for ISE in this NICE discussion. So far, the only official position is the
                      one taken by Emmanuel when working with us on the initial ELKS 2000 proposal.



                      --
                      Dominique Colnet & Olivier Zendra

                      ELKS 2000 discussion: http://www.egroups.com/group/eiffel-nice-library
                      ELKS 2000 web site: http://smalleiffel.loria.fr/elks2000
                    • Frieder Monninger
                      ... I decided not to vaste my time reading postings like this one by Marcel Satchell. Fortunately my mail system has a good filter [it recognises the original
                      Message 10 of 17 , Sep 8, 1999
                      • 0 Attachment
                        At 02:00 08.09.99 -0700, you wrote:
                        >Marcel Satchell wrote:
                        >
                        >> Not quite. ISE came first. EiffelBase is first among data structure
                        >> libraries. The SmallEiffel libraries are not well written - not the
                        >> last time I looked at them. They are a mess; the algorithmic integrity
                        >> is irrelevant (and may well be excellent), but the class texts
                        >> themselves,
                        >> what I have seen of them and the compiler texts, are something to be
                        >> ashamed of. Perhaps more recent versions are better. The VisualEiffel
                        >> libraries are even worse.
                        >
                        >So SmallEiffel is bad, Visual Eiffel worse, and ISE EiffelBase an
                        >example to follow... This would be laughable if it were not a serious
                        >matter.

                        I decided not to vaste my time reading postings like this one by Marcel
                        Satchell.
                        Fortunately my mail system has a good filter [it recognises the original
                        sender],
                        so the problem is solved already :-) - but this works not always as this mail
                        came tru Dominique - so I read it.

                        Its nice to hear such detailled, polite and qualified opinions about the VE
                        libraries.
                        We always thought they were clean, simple and easy to use - in our eyes the
                        most important attributes of a library (and of a language - that's the
                        reason I like
                        Eiffel so much). But, maybe we are wrong :-(

                        Btw, one of our libraries them got the second rank in the last Eiffel Class
                        struggle -
                        so at least 2-3 people (the judges) agreed apparently with out viewpoint.

                        --
                        Frieder Monninger
                        Object Tools GmbH

                        fm@... --- http://www.object-tools.com
                        Nordstr. 5 - D 35619 Braunfels - fon +49 6472 911 030 fax 031
                      • dominique.colnet@loria.fr
                        ... Our real opinion is also our official one ;-) We don t rely on assembly code, since we trust the C compiler to take care of these optimizations. We in fact
                        Message 11 of 17 , Sep 8, 1999
                        • 0 Attachment
                          Frieder Monninger wrote:

                          > because memory move is not supported in Eiffel. (I speak about
                          > the I386 here). It really can be done extremly fast - with in line
                          > assembly
                          >
                          > Whats your real opinion :-) - not the "official" one ??

                          Our real opinion is also our official one ;-)
                          We don't rely on assembly code, since we trust the C compiler
                          to take care of these optimizations. We in fact write as much
                          as we can in Eiffel, trusting the Eiffel compiler to generate
                          good optimized C code.


                          --
                          Dominique Colnet & Olivier Zendra

                          ELKS 2000 discussion: http://www.egroups.com/group/eiffel-nice-library
                          ELKS 2000 web site: http://smalleiffel.loria.fr/elks2000
                        • dominique.colnet@loria.fr
                          ... Agreed. We were just answering Frieder s post, but we may indeed have been a bit off-topic. Also note that the current proposal uses add for ARRAY, since
                          Message 12 of 17 , Sep 15, 1999
                          • 0 Attachment
                            Alexander Kogtenkov wrote:

                            > Frieder Monninger wrote:
                            >
                            > >> because memory move is not supported in Eiffel. (I speak about
                            > >> the I386 here). It really can be done extremly fast - with in line
                            > >> assembly
                            >
                            > Dominique Colnet & Olivier Zendra
                            >
                            > >We don't rely on assembly code, since we trust the C compiler
                            > >to take care of these optimizations. We in fact write as much
                            > >as we can in Eiffel, trusting the Eiffel compiler to generate
                            > >good optimized C code.
                            >
                            > In fact the question was "should we include 'insert' in the ARRAY
                            > or not". It does not matter how it is implemented.

                            Agreed. We were just answering Frieder's post, but we may indeed
                            have been a bit off-topic.

                            Also note that the current proposal uses 'add' for ARRAY, since when
                            the initial ELKS 2000 proposal was worked on, we (SmallEiffel team
                            and Emmanuela Stapf, from ISE) tought it made more sense than
                            'insert_x', especially when considering 'add_last' vs.'insert_last'...


                            --
                            Dominique Colnet & Olivier Zendra

                            ELKS 2000 discussion: http://www.egroups.com/group/eiffel-nice-library
                            ELKS 2000 web site: http://smalleiffel.loria.fr/elks2000
                          Your message has been successfully submitted and would be delivered to recipients shortly.