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

Status

Expand Messages
  • Roger Browne
    I ll be away for a few weeks from today. Here s a summary of where we are at: The ELKS 2001 STRING proposal was submitted to the NICE Board, who are voting on
    Message 1 of 7 , Aug 3, 2001
    • 0 Attachment
      I'll be away for a few weeks from today. Here's a summary of where we are
      at:

      The ELKS 2001 STRING proposal was submitted to the NICE Board, who are
      voting on it. The Board vote is not yet concluded. After the vote, the
      proposal will be posted to the eiffel-nice-discuss mailing list. Every
      standard approved by the Board must be ratified by the members, so there
      will then be a vote on the eiffel-nice-discuss list before the proposal
      becomes official.

      The next topics to be addressed on this list (eiffel-nice-library) will
      be:

      1. ARRAY descendants and make_from_array
      2. Merging of GENERAL and ANY
      3. Specification of GENERAL/ANY

      Feel free to discuss any of these issues prior to my return.

      Regards,
      Roger
      --
      Roger Browne - roger@... - Everything Eiffel
      19 Eden Park Lancaster LA1 4SJ UK - Phone +44 1524 32428
    • gmc444@yahoo.com
      ... [...] ... Okay :-) Looking back on our archive, it appears that in early 2000 we voted to defer any decisions of make_from_array. It looks like there were
      Message 2 of 7 , Aug 6, 2001
      • 0 Attachment
        --- In eiffel-nice-library@y..., Roger Browne <egroups@e...> wrote:
        [...]
        >
        > The next topics to be addressed on this list (eiffel-nice-library) will
        > be:
        >
        > 1. ARRAY descendants and make_from_array
        > 2. Merging of GENERAL and ANY
        > 3. Specification of GENERAL/ANY

        Okay :-)

        Looking back on our archive, it appears that in early 2000 we voted to
        defer any decisions of make_from_array. It looks like there were three
        issues:
        1) should make_from_array should be part of the standard interface?
        2) If it is, should it be a creator?
        3) Can we make it work for descendents of ARRAY?

        Does this sound correct?

        Vendor status:

        SmallEiffel supports the creation feature
        from_collection (model: COLLECTION[like item])
        -- Initialize the current object with the contents of model.

        require
        model /= Void
        ensure
        lower = model.lower;
        upper = model.upper;
        count = model.count

        ISE 4.5 has the creation feature
        make_from_array (a: ARRAY [G])
        -- Initialize from the items of `a'.
        -- (Useful in proper descendants of class `ARRAY',
        -- to initialize an array-like object from a manifest array.)
        require
        array_exists: a /= void

        Is the 5.0 version the same?

        Halstenbach's online documentation only shows the basic make creation
        feature.

        Was there more to it than this?

        Greg
      • Arno Wagner
        ... Which is a creation feature. As ARRAY inherits from COLLECTION via ARRAYED_COLLECTION, this can have an ARRAY argument. I think it would be better to have
        Message 3 of 7 , Aug 10, 2001
        • 0 Attachment
          On Mon, Aug 06, 2001 at 03:40:27PM -0000, gmc444@... wrote:
          > --- In eiffel-nice-library@y..., Roger Browne <egroups@e...> wrote:
          > [...]
          > >
          > > The next topics to be addressed on this list (eiffel-nice-library) will
          > > be:
          > >
          > > 1. ARRAY descendants and make_from_array
          > > 2. Merging of GENERAL and ANY
          > > 3. Specification of GENERAL/ANY
          >
          > Okay :-)
          >
          > Looking back on our archive, it appears that in early 2000 we voted to
          > defer any decisions of make_from_array. It looks like there were three
          > issues:
          > 1) should make_from_array should be part of the standard interface?
          > 2) If it is, should it be a creator?
          > 3) Can we make it work for descendents of ARRAY?
          >
          > Does this sound correct?
          >
          > Vendor status:
          >
          > SmallEiffel supports the creation feature
          > from_collection (model: COLLECTION[like item])
          > -- Initialize the current object with the contents of model.
          >
          > require
          > model /= Void
          > ensure
          > lower = model.lower;
          > upper = model.upper;
          > count = model.count

          Which is a creation feature. As ARRAY inherits from COLLECTION
          via ARRAYED_COLLECTION, this can have an ARRAY argument.
          I think it would be better to have a feature like this in the
          standard, as COLLECTION is a more general concept than
          ARRAY. (With ARRAY O(1) element access is assumed, COLLECTION
          does not make this assumption, and in fact LINKED_COLLECTION
          has O(n) for array access. For prepending elements the
          situation is reversed.)

          On the other hand AFAIK there is no COLLECTION class in ELKS,
          so introducing the general concept of a sequence of elements
          with index, without any assumption on time or space complexities
          would need the introduction of such a class into the standard.
          Its interface is basically the same as ARRAY's, so this would
          be not so difficult.

          SE does it as follows:


          COLLECTION
          (deferred)
          / \
          / \
          / \
          ARRAYED_COLLECTION LINKED_COLLECTION
          (deferred) (deferred)
          / \ / \
          / \ / \
          / \ / \
          ARRAY FIXED_ARRAY LINKED_LIST TWO_WAY_LINKED_LIST



          The differences are mainly that the LINKED-tree has a fixed
          lower index of 1 (don't think that this is necessary, could
          possibly be changed), the FIXED_ARRAY has a fixed lower index
          of 0 (some speed optimization) and different time and space
          complexity.

          I think this is a sensible arrangement. I don't see a need
          for FIXED_ARRAY, but the other classes give good control over
          the time/space behaviour. 'from_collection' is used to convert
          between the different variants. Very useful.

          OTOH it would take some work. What do the other vendors do here?

          > ISE 4.5 has the creation feature
          > make_from_array (a: ARRAY [G])
          > -- Initialize from the items of `a'.
          > -- (Useful in proper descendants of class `ARRAY',
          > -- to initialize an array-like object from a manifest array.)
          > require
          > array_exists: a /= void
          >
          > Is the 5.0 version the same?
          >
          > Halstenbach's online documentation only shows the basic make creation
          > feature.
          >

          Regrads,
          Arno

          --
          Arno Wagner Dipl. Inform. ETH Zuerich wagner@...
          GnuPG: ID: F0C049F1 FP: 8C E0 6F A5 CC B1 5A 11 ED C7 AD D2 05 5E BB 6F

          Software Engineering is that part of Computer Science which is too
          difficult for the Computer Scientist. - F. L. Bauer.
        • gmc444@yahoo.com
          ... Arno Wagner wrote ... Arno, I agree that it would be very nice to allow a higher level of abstraction than ARRAY to serve as the input
          Message 4 of 7 , Aug 10, 2001
          • 0 Attachment
            I wrote:
            > > SmallEiffel supports the creation feature
            > > from_collection (model: COLLECTION[like item])
            > > -- Initialize the current object with the contents of model.
            > >
            > > require
            > > model /= Void
            > > ensure
            > > lower = model.lower;
            > > upper = model.upper;
            > > count = model.count
            >

            Arno Wagner <arno.wagner@a...> wrote

            > I think it would be better to have a feature like this in the
            > standard, as COLLECTION is a more general concept than
            > ARRAY. (With ARRAY O(1) element access is assumed, COLLECTION
            > does not make this assumption, and in fact LINKED_COLLECTION
            > has O(n) for array access. For prepending elements the
            > situation is reversed.)
            >
            > On the other hand AFAIK there is no COLLECTION class in ELKS,
            > so introducing the general concept of a sequence of elements
            > with index, without any assumption on time or space complexities
            > would need the introduction of such a class into the standard.
            > Its interface is basically the same as ARRAY's, so this would
            > be not so difficult.

            Arno, I agree that it would be very nice to allow a higher level of
            abstraction than ARRAY to serve as the input parameter. It would make
            it very convenient to take any child of COLLECTION and move it into a
            new representation. In looking at the ISE implementation of ARRAY,
            though, it looks like this might be a daunting task. ARRAY's heirarchy
            looks something like:

            COLLECTION
            BAG
            TABLE
            INDEXABLE
            ARRAY

            And a COLLECTION is not in itself traversable. One first has to
            convert it to a LINEAR representation.

            (I have no idea how Halstenbach does it, haven't taken the time to
            research it.)

            So the expedient path may be to work with the ARRAY level of abstraction.

            Greg
          • Emmanuel STAPF [ISE]
            The idea of creating an array from a given COLLECTION is quite nice, but I believe it will not help ELKS. What we are looking here for NICE and ELKS is to
            Message 5 of 7 , Aug 10, 2001
            • 0 Attachment
              The idea of creating an array from a given COLLECTION is quite nice, but I
              believe it will not help ELKS. What we are looking here for NICE and ELKS is to
              specify a small set of classes to enable Eiffel compilers interoperability.
              Adding new classes in ELKS will not make this goal easy.

              Regarding the question about the 5.0 version of `make_from_array', we haven't
              changed it.

              From my experience in the ECMA standardization process for .NET, they divided
              the task by introducing the notion of Profile and libraries. A profile is a
              combination of libraries. And a libraries is not something we are used to in the
              Eiffel world. A Library is a set of classes and features.

              For example, let's suppose that DOUBLE is not part of the kernel library, but
              part of the numeric library. So in the kernel library there is nothing that
              reference DOUBLE. However in the numeric library, it adds features to classes of
              the kernel library. For example, if you have a compliant Eiffel compiler that
              both implements the kernel library and the numeric library, you will have access
              in class STRING to the feature `is_double', `to_double'.

              This is quite complicated, but it has the advantage of giving more freedom to
              the standardization people and also enable people implementing the standard to
              be conformant to a minimum level, here the kernel library.

              It is just an informative email and I'm not pushing for a solution like that at
              the moment.
              Regards,
              Manu
            • Arno Wagner
              ... Not very similar to SE s approach. Well, I had to ask. Sometimes problems you expect are not there. Seems this one is. ... I agree. For a first
              Message 6 of 7 , Aug 10, 2001
              • 0 Attachment
                On Fri, Aug 10, 2001 at 06:24:12PM -0000, gmc444@... wrote:
                > I wrote:
                > > > SmallEiffel supports the creation feature
                > > > from_collection (model: COLLECTION[like item])
                > > > -- Initialize the current object with the contents of model.
                > > >
                > > > require
                > > > model /= Void
                > > > ensure
                > > > lower = model.lower;
                > > > upper = model.upper;
                > > > count = model.count
                > >
                >
                > Arno Wagner <arno.wagner@a...> wrote
                >
                > > I think it would be better to have a feature like this in the
                > > standard, as COLLECTION is a more general concept than
                > > ARRAY. (With ARRAY O(1) element access is assumed, COLLECTION
                > > does not make this assumption, and in fact LINKED_COLLECTION
                > > has O(n) for array access. For prepending elements the
                > > situation is reversed.)
                > >
                > > On the other hand AFAIK there is no COLLECTION class in ELKS,
                > > so introducing the general concept of a sequence of elements
                > > with index, without any assumption on time or space complexities
                > > would need the introduction of such a class into the standard.
                > > Its interface is basically the same as ARRAY's, so this would
                > > be not so difficult.
                >
                > Arno, I agree that it would be very nice to allow a higher level of
                > abstraction than ARRAY to serve as the input parameter. It would make
                > it very convenient to take any child of COLLECTION and move it into a
                > new representation. In looking at the ISE implementation of ARRAY,
                > though, it looks like this might be a daunting task. ARRAY's heirarchy
                > looks something like:
                >
                > COLLECTION
                > BAG
                > TABLE
                > INDEXABLE
                > ARRAY
                >
                > And a COLLECTION is not in itself traversable. One first has to
                > convert it to a LINEAR representation.

                Not very similar to SE's approach. Well, I had to ask. Sometimes
                problems you expect are not there. Seems this one is.

                > (I have no idea how Halstenbach does it, haven't taken the time to
                > research it.)
                >
                > So the expedient path may be to work with the ARRAY level of abstraction.

                I agree. For a first approximation ARRAY _is_ enough. For more
                people can use GOBO or something like it. (Frieder Monninger
                suggested this to me in a side conversation.)

                Regards,
                Arno

                --
                Arno Wagner Dipl. Inform. ETH Zuerich wagner@...
                GnuPG: ID: F0C049F1 FP: 8C E0 6F A5 CC B1 5A 11 ED C7 AD D2 05 5E BB 6F

                Software Engineering is that part of Computer Science which is too
                difficult for the Computer Scientist. - F. L. Bauer.
              • Arno Wagner
                ... In this case, it will obviously not :-/ ... So this is something like a hirachical approach with different levels of compatibility? Sounds good for
                Message 7 of 7 , Aug 10, 2001
                • 0 Attachment
                  On Fri, Aug 10, 2001 at 11:41:24AM -0700, Emmanuel STAPF [ISE] wrote:
                  > The idea of creating an array from a given COLLECTION is quite nice,
                  > but I believe it will not help ELKS. What we are looking here for
                  > NICE and ELKS is to specify a small set of classes to enable Eiffel
                  > compilers interoperability. Adding new classes in ELKS will not
                  > make this goal easy.

                  In this case, it will obviously not :-/

                  > Regarding the question about the 5.0 version of `make_from_array',
                  > we haven't changed it.
                  >
                  > > From my experience in the ECMA standardization process for .NET,
                  > they divided the task by introducing the notion of Profile and
                  > libraries. A profile is a combination of libraries. And a
                  > libraries is not something we are used to in the
                  > Eiffel world. A Library is a set of classes and features.
                  >
                  > For example, let's suppose that DOUBLE is not part of the kernel
                  > library, but part of the numeric library. So in the kernel library
                  > there is nothing that reference DOUBLE. However in the numeric
                  > library, it adds features to classes of the kernel library. For
                  > example, if you have a compliant Eiffel compiler that both
                  > implements the kernel library and the numeric library, you will
                  > have access in class STRING to the feature `is_double', `to_double'.
                  >
                  > This is quite complicated, but it has the advantage of giving more
                  > freedom to the standardization people and also enable people
                  > implementing the standard to be conformant to a minimum level,
                  > here the kernel library.

                  So this is something like a hirachical approach with different
                  levels of compatibility? Sounds good for standardization, but
                  must be real nasty to update an implementation when a new
                  "library" is added.

                  > It is just an informative email and I'm not pushing for a solution
                  > like that at the moment.

                  I thibk a process like that is good for a fast and relatively short
                  standardization process. What we do here is rather the other way
                  round :-)=) Not that the fast & short process is necessarily better,
                  see Java for example. But MS wants this in the market soon to save
                  their necks from the ugly vision of a world where nobody actually
                  is dependent on _their_ products anymore.

                  Regards,
                  Arno

                  --
                  Arno Wagner Dipl. Inform. ETH Zuerich wagner@...
                  GnuPG: ID: F0C049F1 FP: 8C E0 6F A5 CC B1 5A 11 ED C7 AD D2 05 5E BB 6F

                  Software Engineering is that part of Computer Science which is too
                  difficult for the Computer Scientist. - F. L. Bauer.
                Your message has been successfully submitted and would be delivered to recipients shortly.