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

Proposed Schedule

Expand Messages
  • Arno Wagner
    It seems people are awake now ;-) Before everybody runs off in a different direction, here is a proposal for a schedule, annotated with some of the problems I
    Message 1 of 1 , Jul 26, 2002
    • 0 Attachment
      It seems people are awake now ;-)

      Before everybody runs off in a different direction,
      here is a proposal for a schedule, annotated with some
      of the problems I expect will come up the discussion.

      My understanding is that we submit every individual class
      to NICE for standardization as soon as we have finished
      with it here. Is that correct?

      First the general properties:


      2. HASHABLE
      Here we get the nice problem that 1) we do not know
      the size of INTEGER 2) we don't have unsigned
      integers. As result arithmetic on hash-codes
      (perfectly ordinary to come up with hash-codes
      of compound objects) can horribly fail by
      resulting in negative values.

      3. NUMERIC
      This does model a commutative ring.

      However most of the ring _properties_ are not modeled.
      Most of these we will have to do non-executable (no
      all-quantification in Eiffel contracts), but the are

      Now to the specific types. Here we have the problem that
      there are some things in PLATFORM that make sense and some
      that do not. Some things are missing. E.g. why no description
      of the REAL value range? What is the use of Pointer_bits?
      Personally I think this whole class is a mistake, as e.g.
      'Maximum_integer' is a property of INTEGER.
      Anyway, I propose we look at the relevant features in PLATFORM
      while going over the following classes. At the end we can
      finalize PLATFORM.
      BTW, is there a reason the features in PLATFORM have names
      starting with a capital letter?

      4. Find out the relation a class and its _REF version have.
      In SE, e.g. BOOLEAN inherits BOOLEAN_REF and BOOLEAN_REF
      defines all the operations BOOLEAN has. This avoids the
      horrible situation in Java, where it is not possible
      to directly use reference types. Instead you have
      to unpack, operate, re-pack. Ugly, ugly, ugly.

      We need to discuss what the vendors do and then decide.

      I propose we start with something simpler than INTEGER.

      At the moment I find it peculiar that BOOLEAN seems not
      to be COMPARABLE. Probably something to fix.

      The first real one. I don't expect significant problems.

      7. Known length integers, known length unsigned integers?
      I feel this would be the best time to discuss them,
      as we have a current and full understanding of what
      it means to be INTEGER. Unsigned should not be a problem,
      after all we only model a ring and 2-s complement
      arithmetic does not care about signs in addition and

      If we run into serious problems, we can conclude this
      unfinished and pick it up later. We can also defer
      the final decision, even if we do agree on things.
      We could do this by having a provisional vote at the end
      that does not yet fix that these things become standard,
      but does fix how they look like if they should become

      The main issue here is probably IEEE754. I think
      that the minimal thing needed is a set of flags in PLATFORM
      that says e.g. 'double_is_IEEE754'. However we need to
      discuss things like +inf, -inf and NaN as they arise in
      practice and are allowed by the last c standard. So maybe
      flags like 'real_has_inf' and 'real_has_nan' may
      be needed.

      We had some things missing in CHARACTER when we did STRING.
      Most notably the notion of whitespace, but also that of case.
      (BTW the link to STRING from yahoogroups is broken...)

      We should discuss Unicode here, but we should not try to
      standardize it, only come to some idea in what way Unicode could
      be introduced that does not disrupt CHARACTER and STRING.

      My proposal would be to make it a separate concept with
      "UNICODE_CHARACTER" and "UNICODE_STRING", or maybe only
      "UNICODE_STRING", as the notion of a character seems to be
      diffuse in Unicode (I am not an expert on this). However I would
      strongly propose that we reach a decision on this, be it that
      CHARACTER is definitely and forever not UNICODE or that it can be
      in a specific, documented and testable way or whatever.
      We also might want to do this in a way that is generic, so
      other text encodings can be supported in a similar way.

      Unicode definitely does not everything and some people might
      want to have a generic, clear way to introduce leaner or
      richer or generally different encodings.

      I guess the issues here will most likely be about
      external usage and interfacing.

      11. Finalize PLATFORM

      12. Pick up known size ints and u_ints if needed.

      13. Open Pandora's Box: FILE and stream I/O.
      This might take longer.

      14. Have a vacation and think about other things.

      I believe this is a workable schedule and has a reasonable
      causality chain in it.

      Questions, comments, things I forgot?


      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
    Your message has been successfully submitted and would be delivered to recipients shortly.