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

Re: New Efforts

Expand Messages
  • Arno Wagner
    Now I have done it... ... It seems I now kind of volunteered to do this.... ... That would be nice. Roger s shoes definitely do not fit me at the moment, but I
    Message 1 of 9 , Jul 24, 2002
    • 0 Attachment
      Now I have done it...

      On Tue, Jul 23, 2002 at 04:36:12PM -0700, Greg C wrote:
      > Hello, Arno. Actually, after Roger Browne took a break, it appears no one
      > wanted to step into his large shoes and stand up with an agenda.

      It seems I now kind of volunteered to do this....

      > So while you're standing in them, can I help you with the knots? :-)

      That would be nice.
      Roger's shoes definitely do not fit me at the moment, but I can give
      it a try. Maybe in time I can become an acceptable substitute....
      (Unless someone else wants to???)


      About the further direction
      ============================

      > > One thing we should think about is what is most needed and
      > > should be done next.

      I am going to compile a list what currently open things we have.
      This is not it yet, just some intermediate version.

      1. I remember that we had some open issues when working on STRING. If
      memory serves that was mostly in CHARACTER and COMPARABLE. But I
      will have to go through the archives to find out.

      2. Franck suggested
      > Go on working on ANY, COMPARABLE, then NUMERIC and the concrete
      > types?

      Sounds reasonable.

      3.Greg wants
      > I'd like to very much see tackled is file I/O.

      While Berend thinks
      > Gobo already has classes for the most common IO operations,
      > and its more than a lowest common denominator. Works with all
      > Eiffel compilers across all platforms.

      I am only working with Gobo for a short time now, and I did
      not notice these classes. Is this in the KL_... classes?

      If Eric already has working solutions here, we could take
      them as an inspiration (if Eric agrees) and specify a subset.
      While having this classes in Gobo is nice, having their basic
      mechanism in ELKS should be the long-term goal. That would also
      make Eric's life easier.

      4. Berend wants to have a work-over on POINTER, INTEGER and related
      classes.

      Personally I would like to see INTEGER to be supplemented by
      positives and variants that have specific bit size (see below), so
      things like overflow can be handled and modern algebraic algorithms
      become feasible (think e.g. crypto, PRNGs, compression,...).
      Before anybody says that is what C code is for, I implemented
      the mersenne twister (http://www.math.keio.ac.jp/~matumoto/emt.html)
      in SE without using C code and got reasonable performance. With
      known-size ints and uints I could have done this in a portable
      way.

      5. Somewhat related to the last point is random number
      generation and (related because of PRNG initialization)
      time. I would like to have ELKS provide basic classes
      here, and maybe even specify a good PRNG as default,
      like the mentioned mersenne twister. This question is
      not easy. E.g. current PRNGs in SE have broken contracts.

      For time, I would not want to do full, international
      time classes, just basic mechanisms for getting a
      primitive representation, like "seconds since the epoch,
      may be negative and is stored in signed 64 bit integer".
      Gobo seems to do a good job of providing more, but basic
      functionality should be ELKS.

      Anything else? I propose we collect items for a week or two
      and then I'll try to come up with an agenda.


      In addition Ulrich would like to have some discussion about whether to
      specify the complete set of ancestors an ELKS class might have. It
      seems this discussion already is in progress.

      My personal view is that it is more of a sideshow, as it implies a
      complete work-over of all ELKS classes, which I think we cannot do at
      the moment (be it merited or not). Of course we still have to specify
      required conformance, like that INTEGER is COMPARABLE.


      Incidentally, as the question will come up: Does anybody here knows
      how to start a poll? Seems the interface does not allow me to. Do
      I need some kind of moderator permissions?


      About ECMA:
      ===========

      Greg said
      > Is ECMA involved in just standardizing the language, or are they also
      > concerned with library issues? Is ECMA getting buy-in from all the Eiffel
      > compiler vendors? I for one would think it acceptable if we divided the
      > standards works between ECMA on language and NICE on libraries.

      Franck said
      > Seems pretty straightforward: ECMA does language and we can
      > continue work on the kernel library. As long as we have the
      > vendor's representative taking part we're safe that our efforts
      > should not be wasted.

      I am pretty sure ECMA will get support from all the vendors.
      As far as I understood only language issues are addressed in
      the upcoming standard. But while I was at the public talks
      in the morning, I am not a member of the standardization group.

      Anybody here that is and can keep us updated about what is going
      on and warn us (and them) when we encounter possible conflicts?

      Even if ECMA only does language, there are grey areas. One thing
      I wanted for a long time is classes for signed/unsigned integers
      with specific size (a la int8,int16,int32,int64,int128,uint16,
      uint32,uint64,uint128). While a library question, this is quite
      near to the compiler. So is this us, ECMA or both?
      (Side note: _Can_ we expand ELKS here, to include e.g. things
      like INT8? What would be the procedure? The same as a discussion
      that proposes changes to an existing class?)



      That about seems to sum it up for the moment.

      Regards,
      Arno




      --
      Arno Wagner, Communication Systems Group, ETH Zuerich, wagner@...
      GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F
      ----
      For every complex problem there is an answer that is clear, simple,
      and wrong. -- H L Mencken
    • Eric Bezault
      ... http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gobo-eiffel/gobo/library/kernel/io/ ... No problem with me. However note that although I m quite happy with
      Message 2 of 9 , Jul 25, 2002
      • 0 Attachment
        Arno Wagner wrote:
        >
        > 3.Greg wants
        > > I'd like to very much see tackled is file I/O.
        >
        > While Berend thinks
        > > Gobo already has classes for the most common IO operations,
        > > and its more than a lowest common denominator. Works with all
        > > Eiffel compilers across all platforms.
        >
        > I am only working with Gobo for a short time now, and I did
        > not notice these classes. Is this in the KL_... classes?

        http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/gobo-eiffel/gobo/library/kernel/io/

        > If Eric already has working solutions here, we could take
        > them as an inspiration (if Eric agrees) and specify a subset.

        No problem with me. However note that although I'm quite happy
        with the design, it contains many classes in the inheritance
        hierarchy (in order to allow not only the class interface specifiation
        of files, but also of other kinds of input/output classes, even
        those not necessarily based on CHARACTERs and STRINGs), and some
        people might think that they are too many for kernel classes.

        --
        Eric Bezault
        mailto:ericb@...
        http://www.gobosoft.com

        ______________________________________________________________________________
        ifrance.com, l'email gratuit le plus complet de l'Internet !
        vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
        http://www.ifrance.com/_reloc/email.emailif
      • Franck Arnaud
        ... Good news! ... Yes, but this is new to Gobo CVS/3.0, not in 2.0 (well the functionality was there in helper routines only). ... Yes. (Although arguably it
        Message 3 of 9 , Jul 25, 2002
        • 0 Attachment
          Arno:

          > It seems I now kind of volunteered to do this....

          Good news!

          > I am only working with Gobo for a short time now, and I did
          > not notice these classes. Is this in the KL_... classes?

          Yes, but this is new to Gobo CVS/3.0, not in 2.0 (well the
          functionality was there in helper routines only).

          > While having this classes in Gobo is nice, having their basic
          > mechanism in ELKS should be the long-term goal. That would also
          > make Eric's life easier.

          Yes. (Although arguably it would make Eric's life easier only in
          the medium term. In the short term after the agreement of a standard,
          there's a risk some compilers and not others are implementing the
          ELKS interface, that you need to track until everybody does it
          correctly.)

          > 4. Berend wants to have a work-over on POINTER, INTEGER and related
          > classes.

          I think it makes sense to do NUMERIC and COMPARABLE first, at least
          for INTEGER which gets most of its interface from parents.

          > Personally I would like to see INTEGER to be supplemented by

          Before adding things we need to specify what is there rigorously.
          Actually I think the numbers should be easier than STRING/ARRAY
          (the main portability problems I can think of the top of my head
          is the power operator and negative modulo semantics).

          When that's done I agree fixed size arithmetic could be useful,
          and it's certainly a common request.

          > 5. Somewhat related to the last point is random number
          > generation and (related because of PRNG initialization)

          I'm not sure it's wise to put that in the kernel. A trivial
          (time seeded) RNG is pure library and has nothing to do in
          the kernel (as long as you have a way to get the time). A
          (new) kernel facility should pass the test that it should
          be hard or impossible to implement efficiently in terms
          of existing kernel facilities.

          A say crypto quality RNG could maybe pass that test, but
          it is difficult to specify and verify (it's far too easy to
          pretend) so I'd be inclined to leave it to entropy generation
          libraries or operating system facilities (like /dev/[u]random
          on Linux, which can be used from a kernel that includes file
          IO).

          Also the number of applications that need real randomness
          is tiny, so another reason not to put in the kernel.

          > "seconds since the epoch,

          That's very ugly. I can't think on any excuse to return
          something other then year/month/day for the date. Time
          within the day may have several equally acceptable
          reprensentations.

          Without getting into full internationalisation, you still
          get at least the GMT vs. local time issue to deal with in
          the kernel (if only to choose one or the other).

          > My personal view is that it is more of a sideshow, as it implies a
          > complete work-over of all ELKS classes, which I think we cannot do at
          > the moment (be it merited or not). Of course we still have to specify
          > required conformance, like that INTEGER is COMPARABLE.

          Agreed.

          > (Side note: _Can_ we expand ELKS here, to include e.g. things
          > like INT8? What would be the procedure? The same as a discussion
          > that proposes changes to an existing class?)

          I think we basically should look at what vendors currently offer,
          and if they:
          - all do the same thing, or something very similar,
          standardise that.
          - 1 or more do something similar, the others nothing
          see if others agree doing like the first group,
          standardise that.
          - nobody does anything, we can design something new.
          - the difficult bit is if they all do it differently ...

          For signed INTEGERs I think ISE has something which could be
          a starting point (I believe others have nothing but I have
          not checked).

          On INTEGERs another thing that may be needed is variable
          size integers (integers that cannot overflow), although
          it is a bit at the limit of something which may belong
          more to Gobo than the kernel as you can implement it
          from well defined fixed size integers.

          --
          franck@...
        • Ulrich Windl
          ... Interesting statement: We heard before that base classes (kernel classes) to not specify what they inherit (i.e. I thought we d see the flat-short form of
          Message 4 of 9 , Jul 25, 2002
          • 0 Attachment
            On 25 Jul 2002, at 23:24, Franck Arnaud wrote:

            > I think it makes sense to do NUMERIC and COMPARABLE first, at least
            > for INTEGER which gets most of its interface from parents.
            >

            Interesting statement: We heard before that base classes (kernel
            classes) to not specify what they inherit (i.e. I thought we'd see the
            flat-short form of the standard specification).

            Are we now claiming that INTEGER _is_ COMPARABLE in the sense of
            "inherit" ;-)

            I would very much agree with that. (Just as ARRAY _is_ some kind of
            collection, but which one exactly)

            Regards,
            Ulrich
          • Franck Arnaud
            ... I think the question is not whether we can specify inheritance or not, but if we can specify a hierarchy that vendors can agree on. In the case of ARRAY
            Message 5 of 9 , Jul 26, 2002
            • 0 Attachment
              > Are we now claiming that INTEGER _is_ COMPARABLE in the sense of
              > "inherit" ;-)

              I think the question is not whether we can specify inheritance
              or not, but if we can specify a hierarchy that vendors can
              agree on. In the case of ARRAY and STRING, it's very unlikely.
              In the case of NUMERIC/COMPARABLE (and ANY) we start from a
              point where everybody does the same thing. Arguably it's a
              bit ironic given that using polymorphism on expanded types
              like INTEGER and friends is not really usable, while
              ancestors of STRING/ARRAY would be directly usable.

              --
              franck@...
            • Greg C
              First, I want to apologize for slipping up and sending out a copy of a digest. Yahoo mail and I don t always get along. Second, Arno is off to a good start
              Message 6 of 9 , Jul 26, 2002
              • 0 Attachment
                First, I want to apologize for slipping up and sending out a copy of a
                digest. Yahoo mail and I don't always get along.

                Second, Arno is off to a good start here in leading discussion and
                summarizing what's gone before. I'm will back off on the file I/O
                standardization if there's consensus about picking up the base classes
                mentioned by Berend and others, esp. INTEGER and its precursors.

                It seems that COMPARABLE and NUMERIC are common base classes for INTEGER
                among all compilers, and reasonable places to start discussion. And since
                both classes affect other classes, having them standardized sounds good.

                One of the disciplines Roger enforced was to avoid doing design on the
                fly, or adding extensions, and instead focus on standardizing common
                functionality already available among the various compilers. I think this
                was a very successful approach that we should continue to apply.

                So can we begin with a comparison of the short forms of COMPARABLE?

                Greg



                =====
                Apologies for the stupid Yahoo ad below.

                __________________________________________________
                Do You Yahoo!?
                Yahoo! Health - Feel better, live better
                http://health.yahoo.com
              • Roger Browne
                Hi everyone, It seems that Arno is keen to take the bull by the horns , and steer this group forwards. Arno courteously emailed me to seek my approval. Arno s
                Message 7 of 9 , Jul 30, 2002
                • 0 Attachment
                  Hi everyone,

                  It seems that Arno is keen to "take the bull by the horns", and steer this
                  group forwards. Arno courteously emailed me to seek my approval.

                  Arno's move is fine by me - although it is not my OK that is needed. What is
                  important is the support of the Eiffel vendors and the Eiffel community. As
                  long as Arno captures the confidence and support of the vendors and the
                  community, he should proceed. If at any time that is no longer the case,
                  someone else should step in.

                  I've set Arno up with "moderator" privileges for this list - although I
                  never needed to use them for this very civilized group.

                  It was enormously satisfying to me that from 1999 to 2002 I was able to tread
                  a tightrope between the various Eiffel "schools of thought", and to work with
                  this group to achieve some very worthwhile improvements to the
                  interoperability of the ARRAY and STRING classes.

                  Thanks to everyone who made this possible, and especially to the vendors
                  without whose cooperation all of the work would have been fruitless.
                  Standards, no matter how worthwhile, are useless unless they get implemented.

                  Although I will continue to monitor this group, and will probably chip in
                  with the occasional comment, I doubt that I will devote the
                  time and energy to it that I did in the past. One reason is that, in my
                  opinion, the goalposts have shifted.

                  Since the beginning of my involvement with Eiffel in 1989, I have dreamed
                  of a vibrant multi-vendor Eiffel world that, through library
                  interoperability, would support the development of enough Eiffel libraries to
                  enable us to develop just about any kind of software system purely in Eiffel.

                  But it seems to me now that this dream will never be achieved. Instead, we
                  are almost certainly leading towards a world where software systems of all
                  kinds will interoperate using what Bertrand Meyer refers to as the "software
                  bus" - specifically the bus provided by the .NET Common Language
                  Specification.

                  This is both disappointing and exciting. It's (slightly) disappointing
                  because the CLS falls slightly short of Eiffel's high aspirations in a few
                  ways. It's enormously exciting because, after decades of talk, the revolution
                  of software development through reusable components is finally being achieved
                  - and I'd like to see Eiffel (or something Eiffel-like) have a chunk of that
                  action.

                  Not everyone sees the future that way - but for those who do, the pressing
                  need is not for Eiffel compilers to interoperate with each other 'per se',
                  but for Eiffel compilers to be compatible with the CLS. Interoperability
                  between Eiffel vendors then comes "for free".

                  Best wishes for the future work of this group - and thanks again to all those
                  who have contributed over the past few years!

                  Regards,
                  Roger
                Your message has been successfully submitted and would be delivered to recipients shortly.