Re: Ada.Strings.Bounded

[Eric Hughes <eric.eh9@gmail.com>]

On Apr 12, 1:46 pm, Georg Bauhaus <rm.tsoh.plus-
bug.bauh...@maps.futureapps.de> wrote:
> The fixed String is an array, a basic and central piece of Ada.
> Unbounded_String is not an array.

Sure, you can have your array; I have no issue at all with that.  But
Ada.Strings.String is just not a string, not in the way it does
padding, not in its absence of concatenation.

> Both types use the word "string" in their name, which is
> unfortunate.

I consider it more than unfortunate.  I consider it just plain wrong.


> 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?

No.  But this answer is one that hinges on the specifics of the
question, not on generalities.  Arrays have a fixed number of
elements; lists do not.  This is more than a matter of
implementation.  It's a question of specification.

Now these two types do share the property that they are indexable.  A
proper set of universal declarations should be able to capture this
similarity.  This requires a partial specification, in my view, and
that subject is beyond the scope of this message, except to say that
partial specifications and universal types are orthogonal concepts.

Hidden in your question, though, is another issue.  I don't believe
that conversions should be automatic.  I believe they should be
explicitly declared and explicitly defined.

> 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 ;)

There's a pattern in dealing with this issue that deserves
standardization with respect to universal types.
   -- When return is ordinary, then the result adheres to the
universal definition.
   -- When return is exceptional, then there is no requirement that
there's any adherence.
Thus exceptions kick you out of the mathematical assumptions into the
real world, and they do so in a reasonably controlled way.

Eric