Re: Surprise in array concatenation

["jimmaureenrogers@worldnet.att.net" <jimmaureenrogers@worldnet.att.net>]

Gene wrote:
> Thanks for a great discussion.
>
> I didn't say general array indexing is not useful; it obviously is. I
> said it's marginally useful in the literal (economist's) sense of "at
> the margin."  A few illustrations...
>
> 1) If one had to give up a feature in order to get another, many would
> put general array indexing early on the chopping block. Between fixed
> and dynamic length arrays (and in particular bounded/unbounded
> strings), for example, Ada forces one to change from native array
> syntax to a procedural interface that hides re-sizing details.  Ada
> programmers I know would happily give up general index ranges in order
> to get dynamically resizing arrays with native syntax---at least those
> who have worked in other languages where such are available.

What kinds of projects do those Ada programmers work on? Is performance
a critical requirement? Resizable arrays always provide reduced
performance over fixed size arrays. Even worse, the performance
penalties are driven by the data. This makes successful critical timing
consistency impossible when using resizable arrays.

Ada provides three kinds of strings. Those three kinds are not present
merely for convenience. Each type of string represents a trade-off
between efficiency and flexibility. The default fixed string type is
the most efficient and least flexible.

>
> 2) General integer ranges for array indices are a half-hearted---at the
> margins---compromise wrt fully general arrays allowing any type as an
> index.  In other words, if you put
> (A) 1-based arrays,
> (B) general discrete type array indices, and
> (C) fully general arrays
> on a conceptual scale, (B) lies _much_ closer to (A) than to (C).

I disagree completely with what you say. General index types are
popular with scripting languages and a few other new languages.
None of those languages concern them selves with execution efficiency
to the extent that Ada does. None of those languages are useful in
hard real-time systems.

Ada language features have not been added merely for the convenience
of the programmer. The Ada language started with genuine design
requirements. Subsequent refinements of the language have not
abandoned the direction and philosophy expressed through those
requirements.

If you want to use a scripting language such as perl, then use perl.
Do not expect all languages to be scripting languages.

>
> 3) The wonder of Ada is the predicatable, orthogonal way that syntax
> and semantics correspond.  But we have just been observing that general
> integer array indexing leads to a not-very-predictable behavior in
> combination with slicing and catenation. If all arrays were 1-based,
> the problem could not have occurred.  Hence this unhappy confluence of
> features, by conflicting with Ada's philosophy, is at the semantic
> margins of the language.  It ought to be avoided if the goal is code
> with obvious meaning. E.g. after I re-coded my original example
> "properly" with 'First and 'Range to make its behavior correct, I
> quickly added a comment, -- 'First is not always 1.  How marginally
> Ada!

In fact the Ada approach is always predictable with regard to slicing
and concatenation. Your experience appears to be rooted in languages
with a different concept of type. For instance, C and C++ have no
array types. One can define an array in each of those languages, but
there is no type tag associated with such an array. One cannot look
up the name of an array type in a C or C++ symbol table.

Ada provides array types. Ada also provides subtypes. Every instance
of an unconstrained array type is constrained. Likewise, every
instance of an unconstrained array type represents a subtype of the
parent unconstrained array type.

All these bits of information are necessary for understanding Ada array
slicing and concatenation. Every Ada array and array slice has a set of
index values. Slicing an array does not "convert" the index values from
their original set to an equivalent size set beginning at 1, 0, or any
other value you might choose. The slice forms a view into the array
from which the slice is taken. It is quite logical, and not the least
marginal, that this view should maintain consistency in its
representation.  When concatenating two arrays, the language must
join the sets of indices in a continuous set of values. Your original
posting marveled that the joining of an empty array with a slice
not starting at 1 resulted in an array whose 'First value was the
same as the slice. Concatenating array A whose indices represent
the null set with array B whose indices represent some non-null set
should always result in an array whose indices are a non-null set.
Moreover, the most efficient and logical merging of the two sets
results in a set idenitcal to the indices of B.

Jim Rogers