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

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

Expand Messages
  • marcel.satchell@eiffel.co.uk
    . ... library... ... I think this is what some wish to avoid, and why EiffelBase has never been made an Eiffel standard. The problems we are having and going
    Message 1 of 17 , Aug 31, 1999
    • 0 Attachment
      .
      >
      > Thinking of it again, perhaps that's not an ELKS problem. But Eiffel
      > _really_ needs a standardized data-structures and algorithms
      library...
      >

      I think this is what some wish to avoid, and why EiffelBase has
      never been made an Eiffel standard.

      The problems we are having and going to have with a even a minimal
      ELKS are formidable enough. Standardising an entire data structure
      library, unless we said it is EiffelBase and the other vendor's
      must adapt their compilers to it, would be a rather formidable
      challenge that I suspect would come to a quick end as people gave
      up in the face of unending disagreement. Perhaps I am unjustifiably
      pessimistic.

      If ELKS2000 is to be, then it must be some time in 2000, lest
      we have to rename it.

      -- Marcel
    • 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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 12 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 13 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.