Re: Ada.Strings.Bounded

[Georg Bauhaus <rm.tsoh.plus-bug.bauhaus@maps.futureapps.de>]

Eric Hughes wrote:
> On Apr 5, 3:43 am, Pascal Obry <pas...@obry.net> 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 relationship.  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.

The fixed String is an array, a basic and central piece of Ada.
Unbounded_String is not an array.

Both types use the word "string" in their name, which is
unfortunate.  They are two very different constructions.
We can use Unbounded_String objects in ways that
are not available with strings: they are lists rather
than fixed arrays.

Seen from this point of view, a more general question is,
do we have standard ways of converting between arrays and lists?
Should these conversions be captured by some "predefined" notion
of universal_array? (Maybe you will find ideas by Dmitry Kazakov
instructive.)

Unfortunately, programming always deals with storage, memory,
and times, in particular when a systems programming language
like Ada is used, and when credit is given to the fact that
programs mean operations of a computer with storage cells,
instructions, and clock ticks. I can imagine values of some
underlying universal_array as part of a nice clean
ivory tower model of mathematical reductionism. Nasty real
world computers ;)

The APL world is different and offers another hint. Maybe
Ada fixed Strings let us think they somehow must have one
dimension, but not 2, 3, or N. Why?
And should universal_array be made capable enough to convert
arrays to lists and vice versa per dimension?