- 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:
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.
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
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.
5. BOOLEAN, BOOLEAN_REF
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.
6. INTEGER, INTEGER_REF
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
8. REAL, REAL_REF, DOUBLE, DOUBLE_REF
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
9. CHARACTER, CHARACTER_REF
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.
10. POINTER, POINTER_REF
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