On Apr 5, 3:43 am, Pascal Obry <pas...@[EMAIL PROTECTED]
> wrote:
> What to do if we have Put_Line defined for String and
> Unbounded_String? Which version gets called?
I know this answer is a bit heretical, but the answer I'd pick is
"either one". Non-deterministic execution, if you'd like the
technical term. Which in practice means that the compiler can pick a
deterministic path and just use that one.
The reason for this is that String and Unbounded_String are not
arbitrarily related in conception. Ada, as presently constituted, is
unable of representing the details of this relation****p. Users of
these types know what they're supposed to do, but the language does
not capture this. A correct implementation of Put_Line should have
the property that the result of Put_Line on a String is the same as
the result of Put_Line on an Unbounded_String converted from the same
String. This is the substance of algebraic specification. So,
assuming (contrary to fact) such a specification, it should not matter
for correctness which version executed.
It would affect performance, true. But it's performance about
symbolic manipulations (in the representation of the type) with
symbols that do not appear in the language itself. Since these
symbols do not appear in the definition of String, it's the wrong path
to try to specify performance choices _at this level of abstraction_.
Some form of (expanded) representation clause is the right place to do
this. Representation clauses are the natural way in Ada to specify
implementation choices.
Back the larger type issue, the ARM contains the types
universal_integer, universal_real, universal_fixed; these are listed
as predefined in ARM 3.2.1/10. (Erratum: not all the predefined types
are listed here.) I find it droll that the term "predefined" is not
defined. It doesn't need to be, really, though. "Everybody knows"
what numbers are supposed to do. The axioms of arithmetic are well-
known, even if all the ordinary numbers of mathematics are
unimplementable on computers (only bounded-length representations are,
even if the bound is indefinite).
I believe many of the issues involving strings could be addressed by
introducing a predefined type universal_string. And then the hard
part: making everything work out right. _Inter alia_, all conversions
between string types would have to preserve the underlying
universal_string value. I would raise Length_Error if a silent
truncation were to occur, under the theory that truncation is an
operation on values (as distinguished from objects and variables) that
should *never* be made silently. And having universal_string should
eliminate most of those unary conversion operators to move between
different string types.
As not-too-much of an aside, this is why the ordinary Strings package
is fatally flawed, because its padding manipulations are just NOT how
universal_string values act. Padding is a bastard child of an
implementation choice (fixed length array) and a discrimination
between characters that matter and the padding character, which
doesn't. That package should really be named Padded_Strings.
Now, my real hope is that universal_string wouldn't need to be
predefined at all, but specified algebraically or logically within a
future version of Ada. But for now the next step is to start with a
predefined type.
Eric
|
