From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,db88d0444fafe8eb X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!postnews.google.com!f14g2000cwb.googlegroups.com!not-for-mail From: "jimmaureenrogers@worldnet.att.net" Newsgroups: comp.lang.ada Subject: Re: Surprise in array concatenation Date: 5 Sep 2005 10:47:14 -0700 Organization: http://groups.google.com Message-ID: <1125942434.046551.206180@f14g2000cwb.googlegroups.com> References: <1125610942.747981.280770@f14g2000cwb.googlegroups.com> <1125935610.797293.40550@g43g2000cwa.googlegroups.com> NNTP-Posting-Host: 69.170.70.49 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1125942439 7838 127.0.0.1 (5 Sep 2005 17:47:19 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Mon, 5 Sep 2005 17:47:19 +0000 (UTC) In-Reply-To: <1125935610.797293.40550@g43g2000cwa.googlegroups.com> User-Agent: G2/0.2 X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10,gzip(gfe),gzip(gfe) Complaints-To: groups-abuse@google.com Injection-Info: f14g2000cwb.googlegroups.com; posting-host=69.170.70.49; posting-account=SqOfxAwAAAAkL81YAPGH1JdBwpUXw9ZG Xref: g2news1.google.com comp.lang.ada:4446 Date: 2005-09-05T10:47:14-07:00 List-Id: 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